Microsoft Exchange Server 2010 Best Practices

Microsoft Exchange Server 2010 Best Practices
Microsoft Press
A Division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2010 by Joel Stidley and Siegfried Jagott
All rights reserved. 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: 2010929323
Printed and bound in the United States of America.
1 2 3 4 5 6 7 8 9 WCT 5 4 3 2 1 0
A CIP catalogue record for this book is available from the British Library.
Microsoft Press books are available through booksellers and distributors worldwide. For further information about
international editions, contact your local Microsoft Corporation office or contact Microsoft Press International
directly at fax (425) 936-7329. Visit our Web site at Send comments to [email protected]
Microsoft, Microsoft Press, Access, Active Directory, ActiveSync, Entourage, Excel, Forefront, Hotmail, Hyper-V,
InfoPath, Internet Explorer, MS, Outlook, PowerPoint, SharePoint, Silverlight, SmartScreen, SQL Server, Visio, Visual
Basic, Visual C++, Windows, Windows Live, Windows Mobile, Windows NT, Windows PowerShell, Windows Server,
Windows Vista, and Xbox are either registered trademarks or trademarks of the Microsoft group of companies.
Other product and company names mentioned herein may be the trademarks of their respective owners.
The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and
events depicted herein are fictitious. No association with any real company, organization, product, domain name,
e-mail address, logo, person, place, or event is intended or should be inferred.
This book expresses the author’s views and opinions. The information contained in this book is provided without
any express, statutory, or implied warranties. Neither the authors, Microsoft Corporation, nor its resellers, or
distributors will be held liable for any damages caused or alleged to be caused either directly or indirectly by
this book.
Acquisitions Editor: Martin DelRe
Developmental Editor: Karen Szall
Project Editor: Carol Vu
Editorial Production: Christian Holdener, S4Carlisle Publishing Services
Technical Reviewers: Tony Redmond and Scott Schnoll; Technical Review services provided by Content
Master, a member of CM Group, Ltd.
Cover: Tom Draper Design
Body Part No. X17-00144
I dedicate this book to my mum, Johanna, for all the support and
love she gave to me throughout my whole life. Without her effort
I would not be where I am today.
To my wife, Andrea. Without her patience, love, and support
I would not be able to take on new and exciting challenges.
Contents at a Glance
About the Sidebars
Introducing Exchange Server 2010
Exchange Deployment Projects
Exchange Environmental Considerations
Client Access in Exchange 2010
Routing and Transport
Mailbox Services
Edge Transport and Messaging Security
Automated Message Processing,
Compliance, and Archiving
Unified Messaging
Federated Delegation
Designing High Availability
Backup, Restore, and Disaster Recovery
Hardware Planning for Exchange Server 2010
Upgrading from Exchange Server 2003
and Exchange Server 2007
Preparing for and Deploying Exchange
Server 2010
Managing Exchange
Operating and Troubleshooting Exchange
Server 2010
About the Sidebars
Chapter 1
Introducing Exchange Server 2010
The History of Exchange Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
The Years Before Exchange
Exchange Server Before Active Directory
Exchange Server 2000 and 2003
Exchange Server 2007 and Beyond
Overview of Exchange Server 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Management Consoles
Exchange Server Roles
Feature Changes from Exchange 2003 and 2007
Exchange On-Premise versus Exchange Online
Exchange Server 2010 Service Pack 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Exchange 2010 Editions and Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Exchange Server 2010 Editions
Exchange Server 2010 Client Access Licenses
Exchange Organizational Health
Windows PowerShell and Exchange 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Windows PowerShell Basics
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
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:
Chapter 2
Exchange Deployment Projects
Exchange Deployment Project Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Planning Exchange Deployment Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Putting a Project Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Case Studies Used in This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Chapter 3
Exchange Environmental Considerations
Evaluating Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Reviewing Current and Planned Network Topology
Domain Name System (DNS)
Internet Protocol (IPv4 and IPv6)
Understanding Client Load Patterns
Perimeter Network
Avoiding Pitfalls by Providing Technical
Evaluating and Planning for Active Directory . . . . . . . . . . . . . . . . . . . . . . . . 89
How Exchange 2010 Uses Active Directory
Single versus Multi-Forest Implementation
Single vs. Multi-Domain Implementation
Planning Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Server Name
Database Availability Group Name
Database Name
Active Directory Site Name
User Names
Planning Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Namespace Scenarios
Disjoint Namespace
Single Label Domains
Non-contiguous Namespaces
Planning Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
About Digital Certificates
Types of Certificates
Working with Certificates in Exchange 2010
Planning Exchange Server 2010 Placement . . . . . . . . . . . . . . . . . . . . . . . . . 116
Domain Controller and Global Catalog Placement
Using Exchange Server 2010 on Member Servers
or Domain Controllers
Exchange Server Role Placement
Planning Network Port Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Mailbox Server
Hub and Edge Transport Servers
Client Access Server
Unified Messaging Server
International Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Multiple Language Support for Exchange
Time, Time Zone, and Daylight Saving
Message Format and Encoding
Mail Client Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Microsoft Outlook/Entourage
Outlook Web App
IMAP and POP3 Clients
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Chapter 4
Client Access in Exchange 2010
Client Access Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Client Access Server Features
Windows Services
New Features
Planning Client Access to Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
Client Access Services and Physical Architecture
Client Access High Availability
Certificates for Client Access Services
Pulling It All Together
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
Chapter 5
Routing and Transport
Exchange Transport Server Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . .203
Components of Message Transport
Message Queues on Transport Servers
Queue Database
Transport Server Services
Delivery Status Notifications
Message Latency Measurement
Shadow Redundancy
Message Throttling
Back Pressure
Understanding Transport Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Default Transport Agents
Events That Trigger Transport Agents
Message Routing in Exchange 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222
Message Routing within an Exchange
Reviewing and Configuring Message Routing
Between Active Directory Sites
Planning Message Routing to the Organization
Planning and Configuring Your SMTP Namespace
TargetAddress Routing
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258
Chapter 6
Mailbox Services
Introduction to Exchange Server 2010 Mailbox Services . . . . . . . . . . . . . . 259
Exchange Mailbox Services Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . .260
Database Files
The Exchange Services
What Is New in Exchange Server 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265
Large Mailboxes
Deleted Item Recovery and Dumpster 2.0
Discontinuation of Storage Groups
Performance Improvements
Exchange Mailbox Services Configuration . . . . . . . . . . . . . . . . . . . . . . . . . .279
Determining the Number of Mailboxes
for Each Server
Determining Where to Host Mailboxes
Database Maintenance
Mailbox Limits
Configuring Deleted Item Recovery Quotas
Poison Mailbox Detection and Correction
Client Configuration
Configuring Public Folders
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295
Chapter 7
Edge Transport and Messaging Security
Implementing Edge Transport Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
Considering Firewall Ports
Planning and Configuring Edge Synchronization
Edge Transport Configurations
Planning for Anti-Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
How Exchange 2010 Does Spam Filtering
How Anti-Spam Updates Work
Enable Anti-Spam on Hub Transport Servers
Connection Filtering
Sender Filtering
Recipient Filtering
Sender ID Filtering
Content Filtering
Sender Reputation Filtering
Attachment Filtering
Anti-Spam Reporting
Antivirus Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
Exchange Server 2010 Antivirus Protection
Considerations for Deploying an Antivirus Solution
Using Forefront Protection 2010 for Exchange Server
Planning for Messaging Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .338
Implementing Network-Based Security
Planning for Session-Based Security
Implementing Client-Based Security
Additional References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344
Chapter 8
Automated Message Processing,
Compliance, and Archiving
Messaging Compliance Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346
Designing and Implementing Messaging Records Management . . . . . .348
Retention Tags and Retention Policies
Retention Hold
Managed Folders
Designing and Implementing Transport Rules . . . . . . . . . . . . . . . . . . . . . . 361
Rules Agents
Creating Transport Rules
Designing and Implementing Message Journaling . . . . . . . . . . . . . . . . . .367
Journaling Agent
Journal Reports
Journal Rules
Designing and Implementing Personal Archives. . . . . . . . . . . . . . . . . . . . . 371
Multi-Mailbox Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Litigation Hold
Performing a Multi-Mailbox Search
Designing and Implementing AD RMS Integration . . . . . . . . . . . . . . . . . .380
AD RMS Overview
AD RMS and Exchange Server 2010
Designing and Implementing Message Classifications . . . . . . . . . . . . . . .399
Dependencies of Message Classification
Creating Message Classifications in Exchange Server 2010
Configuring Message Classifications
for Outlook 2007 and Outlook 2010
Assigning Message Classifications with Transport Rules
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .406
Chapter 9
Unified Messaging
Introduction to Unified Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .408
The Basics of Telephony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Types of Telephone Systems
Types of PBX
VoIP Gateway Introduction
Unified Messaging Protocols
Exchange Unified Messaging Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Unified Messaging Services
Unified Messaging Folder Structure
Planning for Unified Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Unified Messaging Servers
UM Dial Plans
UM IP Gateways
UM Hunt Groups
UM Mailbox Policies
UM Auto Attendants
Call Answering Rules
Deploying Unified Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Adding the UM Server Role
Configuring UM Dial Plans
Configuring UM IP Gateways
Configuring UM Hunt Groups
Configuring UM Mailbox Policies
Configuring UM Settings
Configuring Incoming Faxes
International Considerations of Unified Messaging . . . . . . . . . . . . . . . . . .429
Foreign Language Support
Operating UM in a Multi-language Environment
Managing Unified Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Enabling Mailboxes for Unified Messaging
UM Reporting
Testing Unified Messaging Functionality
Office Communication Server 2007 R2 Integration . . . . . . . . . . . . . . . . . .436
Integrating OCS 2007 R2 in Exchange 2010 Architecture
Deploying UM and OCS 2007 R2 Integration
Deploying Instant Messaging for OWA
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444
Chapter 10 Federated Delegation
Introduction to Federated Delegation
in Exchange Server 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .445
Overview of Federation and Federated Delegation
Fundamentals and Components of Federated Delegation . . . . . . . . . . . .448
Federation Trust
Organization Relationships
Sharing Policies
Interaction of Permissions, Organization
Relationships, and Sharing Policies
Federation Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .461
Free/Busy Access
Calendar and Contacts Sharing
Federating with Online Services
Troubleshooting Federated Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . .467
Troubleshooting the Federation Trust
Troubleshooting Organization Relationships
Troubleshooting Calendar and Contacts Sharing
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Chapter 11 Designing High Availability
Achieving High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .477
Measuring Availability
Exchange 2010 High-Availability Features
Availability Planning for Mailbox Servers . . . . . . . . . . . . . . . . . . . . . . . . . . .480
Continuous Replication
Designing and Configuring DAGs
Availability Planning for Client Access Servers. . . . . . . . . . . . . . . . . . . . . . .500
Client Access Load Balancing and Failover
Availability Planning for Transport Servers. . . . . . . . . . . . . . . . . . . . . . . . . .509
Shadow Redundancy
Planning Cross-site Failovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Cross-site DAG Considerations
Cross-site Considerations for Client Access
and Transport
Risk Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Pulling It All Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .529
Chapter 12 Backup, Restore, and Disaster Recovery
Changes to Backup and Restore in Exchange
Server 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Integrating High Availability
and Disaster Recovery
Removal of ESE Streaming APIs for Backup and Restore
Storage Group Removal
Database Not Tied to a Specific Mailbox Server
Using DAGs to Eliminate Traditional Point-in-Time
Backup and Disaster Recovery Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . .534
Why Backup Is Done
Developing Service Levels for Backup and Restore
Disaster Prevention Strategies
Testing Your Disaster Recovery Plan
Performing Backup and Recovery for Non-Mailbox
Server Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544
Client Access Server Backup and Recovery
Hub Transport Server Backup and Recovery
Unified Messaging Server Backup and Recovery
Edge Transport Server Backup and Recovery
Performing Backup and Recovery for Mailbox
Server Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .548
Volume ShadowCopy Service
Using Windows Server Backup
Using Advanced Backup Solutions
Dial Tone Recovery
Using the Recovery Database
Recover an Exchange Server
Backup and Recovery of Public Folders
Operating Without Traditional Point-in-Time Backups . . . . . . . . . . . . . . .567
Using Lagged Database Copies
Backups and Log File Truncation
Reasons for Traditional Point-in-Time Backups
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Chapter 13 Hardware Planning for Exchange Server 2010
Sizing and Planning Exchange Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Exchange Scalability
The Sizing Process
Sizing Tools
Preproduction Verification
Sizing Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .602
Processor Type
Processor Scalability
Processor Guidelines
Processor Ratio Guidelines
Network Configuration
Domain Controllers
Hub and Edge Transport Roles
Client Access Server Role
Mailbox Role
Unified Messaging Role
Multiple Role Server
Designing Virtualization for Exchange 2010 Servers . . . . . . . . . . . . . . . . . 619
Virtualization Support
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .622
Chapter 14 Upgrading from Exchange Server 2003
and Exchange Server 2007
Designing Upgrade and Coexistence Strategies . . . . . . . . . . . . . . . . . . . . .626
Discontinued and De-emphasized Functionality
in Exchange Server 2010
Useful Tools for an Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Exchange Server Deployment Assistant
Exchange Best Practices Analyzer
Exchange Pre-Deployment Analyzer
Exchange Server Remote Connectivity Analyzer
Upgrading from and Coexisting with Exchange
Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .636
Preparing the Environment
Deploying Exchange Server 2010 Computers
Upgrading Outlook and Remote Access Functionality
Upgrading Message Connectivity From Exchange
Server 2003
Coexistence for Management
Planning and Implementing Mailbox Moves
and Coexistence
Planning Public Folder Access and Migration
Removing Legacy Exchange Servers
Upgrading from and Coexisting with Exchange
Server 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .664
Upgrading Exchange Server 2007 Computers to SP2
Preparing Active Directory After Applying
Exchange Server 2007 SP2
Deploying Exchange Server 2010 Computers
Upgrading Client Access Services
Upgrading Message Connectivity
From Exchange Server 2007
Planning Mailbox Moves and Coexistence
Planning Continuous Replication Migration
Planning Unified Messaging Migration
Removing Exchange Server 2007 Computers
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Chapter 15 Preparing for and Deploying Exchange
Server 2010
The Exchange Server 2010 Deployment Process. . . . . . . . . . . . . . . . . . . . .680
Exchange and Active Directory Domain Services
Preparing for an Exchange Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . .684
Prepare AD DS and Domains
Checking Exchange Environment Health
Deploying Exchange 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Automating Exchange Server Installations . . . . . . . . . . . . . . . . . . . . . . . . . .720
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Chapter 16 Managing Exchange
Exchange 2010 Permissions Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Active Directory Groups of Exchange
The Role-Based Access Control Permission Model
Active Directory Split Permissions
Managing Exchange Recipients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .738
Managing Mail-Enabled Users and Mailboxes
Managing Contacts
Managing Groups
Managing Resources
Moving Mailboxes
Importing and Exporting Mailboxes
Automating Administration
Managing Other Exchange Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Managing Address Policies
Managing Address Lists
Managing Details Templates
Managing Outlook Web App Themes
Managing Public Folders
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .772
Chapter 17 Operating and Troubleshooting Exchange
Server 2010
Microsoft Operations Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .773
Problem vs. Incident Management
Trending and Capacity Planning
Troubleshooting Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Define the Scope
Collect the Data
Correlate the Data
Rank the Causes
Work the Solutions
Return to Operating State
Feedback Loop
Monitoring Exchange Server 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .779
Performance Monitor
System Center Operations Manager 2007 R2
Troubleshooting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
Identifying and Resolving Performance Problems
Identifying and Resolving Mail Flow Issues
Identifying and Resolving Exchange Server Issues
PowerShell Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .812
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
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:
About the Sidebars
his book includes sidebars that provide you with real-world experience and
insights from Microsoft Exchange product group members as well as well
known Exchange subject matter experts. Each sidebar covers a specific topic of
expertise and reflects the opinion of the sidebar contributor, not necessarily the
opinion of Microsoft or the authors of this book.
Sidebars in this book are categorized into the following distinguishing sidebar
Notes from the Field Insights and experiences from Microsoft
consultants, technical support professionals, partners, and early adopter
Inside Track Insider information or tips from Microsoft program
managers, technical product managers, developers, and testers.
Lessons Learned Examples of things that did not go well or what not
to do. Learn from others so that you don’t repeat their mistakes.
Trade-Offs Best practices are rarely absolute. We point out key
decisions that you should be weighing.
Chapter 1
Notes from the Field: “Exchange 4.0 Beta: Codename Touchdown”
by Andreas Essing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Notes from the Field: “Migrating from Microsoft Mail 3.5
to Exchange 4.0” by Gary A. Cooper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Notes from the Field: “The Release of Exchange 4.0 as Experienced
in Germany” by Lars Riehn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Notes from the Field: “When OWA Was Invented”
by Tony Redmond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Notes from the Field: “Right-Click in Exchange System Manager”
by Tony Redmond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Notes from the Field: “Europe’s Issues with Exchange Online”
by Manfred Kornagel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Inside Track: “Windows PowerShell 2.0 Best Practices”
by Ed Wilson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Chapter 2
Notes from the Field: “Gathering Business Requirements”
by John P. Glynn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Notes from the Field: “Assessing a Current Exchange Deployment”
by Joseph Cirillo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Notes from the Field: “Escalations” by John P. Glynn . . . . . . . . . . . . . . . . . . . 61
Chapter 3
Notes from the Field: “DNS Dynamic Updates” by John P. Glynn . . . . . . . . . 76
Notes from the Field: “Identifying Current Client Load”
by Andy Schan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Notes from the Field: “Additional Beneficial Server Settings”
by Joe Cirillo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Inside Track: “How to Safely Extend the Schema” by Ross Smith IV . . . . . . . 91
Notes from the Field: “Planning a Forest Design” by Andrew
Ehrensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Notes from the Field: “A Disjoint Namespace Example”
by Carsten Allendoerfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Notes from the Field: “Planning Exchange Server Roles
and Placement” by Joe Cirillo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
Notes from the Field: “Consider Outlook RPC encryption”
by Ross Smith IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Chapter 4
Inside Track: “BlackBerry and Performance Impacts”
by Robin Thomas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Inside Track: “Service Connection Points and AutoDiscover”
by Greg Taylor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Notes from the Field: “Redirecting OWA URLs in Exchange 2010”
by Brian Desmond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169
Inside Track: “ExternalURLs” by Greg Taylor . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Inside Track: “Client Access Server Array Names” by Greg Taylor . . . . . . . . 175
Notes from the Field: “Client Access Server Sizing Tips”
by Andrew Ehrensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
About the Sidebars
Chapter 5
Inside Track: “Troubleshooting Submission Queue”
by Charlie Chung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
Notes from the Field: “Disable TLS for Hub to Hub Transport
Communication” by Andy Schan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224
Notes from the Field: “A Practical Way to Define Site Link Costs”
by Brian Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Notes from the Field: “Using Exchange Costs on IP Site Links”
by Ulf Hansen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Inside Track: “Scoping Send Connectors Correctly”
by Todd Luttinen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
Inside Track: “Configuring a Failover Scenario with MX Records”
by Ross Smith IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240
Notes from the Field: “Configuring Relaying in Exchange
Server 2010” by Christian Schindler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Chapter 6
Notes from the Field: “Choosing a Disk Technology”
by Steve McIntyre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .270
Notes from the Field: “Segregating Database and Transaction Logs”
by Thierry Demorre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
Notes from the Field: “How Many Mailboxes Should be Created
on a Server?” by Thierry Demorre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282
Notes from the Field: “Appropriately Sizing Mailboxes”
by Thierry Demorre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287
Chapter 7
Notes from the Field: “Edge Transport Role and Forefront TMG”
by Henrik Walther . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299
Notes from the Field: “Make Sure Edge and Hub Authenticate
Correctly” by Christian Schindler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Lessons Learned: “Anti-Spam with Forefront Protection 2010
for Exchange” by Alexander Nikolayev . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Notes from the Field: “Create a Transport Rule to Process SCLs”
by Andreas Bode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328
Notes from the Field: “Custom Agent Log Analyzer” by Jon Webster . . . . 333
About the Sidebars
Chapter 8
Inside Track: “Successfully Implementing Messaging Compliance
Technologies” by Ed Banti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
Notes from the Field: “Journaling and Distribution Lists”
by Thierry Demorre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Inside Track: “Simplifying the End-User Experience with Message
Classifications” by Ed Banti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .401
Chapter 9
Inside Track: “Behind the Scenes of Unified Messaging”
by Ankur Kothari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .409
Inside Track: “Voicemail Preview and CPU Scalability”
by Ankur Kothari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Inside Track: “Languages for Voicemail Preview”
by Ankur Kothari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .429
Notes from the Field: “Changing Language for Voice Mail”
by Korneel Bullens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Notes from the Field: “OCS 2007 R2 Integration: Extension Numbers”
by Korneel Bullens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437
Notes from the Field: “Unified Messaging Transitioning
and Extension Dialing” by Gary A. Cooper. . . . . . . . . . . . . . . . . . . . . . . . .440
Chapter 10
Inside Track: “Cross-Org Free/Busy Access with Outlook 2007
Clients” by Matthias Leibmann. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .462
Inside Track: “Federation Trust and the Federated Organization
Identifier for Cross-Premises Scenarios” by Matthias Leibmann . . . . . .466
Lessons Learned: “Federated Delegation and Pre-Authentication
with Microsoft ISA Server and Forefront Threat Management
Gateway (TMG)” by Devin L. Ganger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .467
Lessons Learned: “Troubleshooting Certificate Rolling
Using Exchange Server 2010 Federation” by Gary A. Cooper . . . . . . . . . 471
About the Sidebars
Chapter 11
Notes from the Field: “Exchange High Availability Improvements”
by Colin Lee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .483
Notes from the Field: “JBOD Impact on Operations
and Risk Discussion” by Arno Zwegers . . . . . . . . . . . . . . . . . . . . . . . . . . . .498
Notes from the Field: “Client Access Namespace and the Impact
to High Availability and Site Resiliency” by Gary A. Cooper . . . . . . . . . . 514
Chapter 12
Notes from the Field: “Backup Pains” by Colin Lee . . . . . . . . . . . . . . . . . . . . 535
Notes from the Field: “The Missing Folder Information
of Single Item Recovery” by Jon Webster . . . . . . . . . . . . . . . . . . . . . . . . . .542
Lessons Learned: “Backup and Restore Options Depend
on Organization Size” by Colin Lee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .548
Notes from the Field: “DPM 2010 vs. Lagged Copies”
by Todd Hawkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .560
Notes from the Field: “An Exchange 2010 Implementation
Without Traditional Point-in-Time Backups” by Sascha Schmatz. . . . . .568
Chapter 13
Notes from the Field: “Profiling Foreign Mail Systems”
by Jeffrey Rosen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .580
Notes from the Field: “Mailbox Server Storage I/O Configuration”
by Arno Zwegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Notes from the Field: “Virtualization—It’s Complicated!”
by Erik Gustafson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .620
Trade-Offs: “Exchange Virtualization—Choosing a Strategy”
by Jeff Mealiffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .621
Chapter 14
Inside Track: “Seamless Coexistence with the Legacy URL”
by Kristian Andaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .643
Notes from the Field: “Optimizing Message Routing in an
Exchange Server 2003 and Exchange Server 2010 Environment”
by Markus Bellmann. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .649
About the Sidebars
Notes from the Field: “Moving Mailboxes from Exchange
Server 2003 to Exchange Server 2010” by Nicolai Wagner . . . . . . . . . . .659
Lessons Learned: “Invalid Categories Set on Public Folder Items”
by Markus Bellmann. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .661
Chapter 15
Notes from the Field: “Installing Only Minimum Prerequisites”
by Andy Schan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
Inside Track: “Exchange Server 2010 Install Differences”
by Paul Wimmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .706
Notes from the Field: “Considerations for Local Security
of Exchange Servers” by Erick Szewczyk . . . . . . . . . . . . . . . . . . . . . . . . . . .719
Notes from the Field: “Performing Exchange Server 2010
Unattended Deployments” by Paul Wimmer . . . . . . . . . . . . . . . . . . . . . .720
Chapter 16
Notes from the Field: “Noticeable Improvements with RBAC”
by Brian Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .727
Notes from the Field: “Restricting Permissions Using Custom
Role Groups” by Ulf Hansen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .734
Notes from the Field: “User and Mailbox Provisioning”
by Andy Schan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .760
Chapter 17
Notes from the Field: “Exchange Perfmon” by Andy Schan . . . . . . . . . . . . .783
Notes from the Field: “Creating a Report of Performance
Data” by Alessandro Goncalves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .785
Notes from the Field: “Exchange and Hyper-V CPU Utilization
Troubleshooting” by Alessandro Goncalves . . . . . . . . . . . . . . . . . . . . . . . .786
Notes from the Field: “Consider Active Directory
Replication Delays in Exchange 2010 Troubleshooting”
by Markus Bellmann. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .787
Notes from the Field: “PowerShell Scripts” by Joe Cirillo . . . . . . . . . . . . . . .807
About the Sidebars
very day we rely more and more on electronic mail to handle our most
basic communication needs. Our reliance leads us to require dependability.
To ensure an efficient transition from an older system to Exchange 2010, you
must determine how to integrate a myriad of systems. Your users will demand
compatibility and high levels of uptime, and managers will demand lower costs
in terms of servers and storage. I have spent 15 years at Microsoft working with
teams to enhance the end-user experience. I’ve never been as excited about
the work we’ve done as I am now with the release of Exchange 2010. With
Exchange 2010, our development team was dedicated to building a brand-new
release that effectively took a deliberate approach to building new features,
refining existing features, and making sure at every step that we stayed true
to our goals of delivering an awesome release of Exchange. The breadth and
depth of the technologies Microsoft Exchange 2010 finally delivers is astounding.
Exchange 2010 provides new features such as Exchange Control Panel (ECP),
Domain on the Middle Tier (DoMT), High Availability (HA), and Role-Based Access
Control (RBAC). Federated sharing, archiving, and lower storage cost options are
knocking down barriers that have traditionally stopped customers from deploying
or meeting user needs. Any one of the features I just mentioned would be
interesting on its own, but the combination is truly compelling.
Exchange is easy to install, but to get the most out of it you need to explore
the many features and capabilities that more than 20 million lines of code bring
to it. You want to understand the software in detail, and the authors of this book
have the experience to show you all of the features and components. The authors
have done an awesome job getting the details right and have taken great care
in bringing you what I think is the best book on the subject. Recently there has
been talk about books like this being out of date as soon as they go to press, or
that getting information from the Internet is the new way to learn. To this I say,
“Nonsense!” With this book, you will gain from the authors’ vast experience with
a topic that is vast in scope. How did the authors get such in-depth, detailed
experience with a product released in November of 2009? That level of detail—
including best practices for deployment—requires time and teamwork, and that is
where the Technology Adoption Program (TAP) comes into play.
Microsoft’s Technology Adoption Program is designed to validate new
versions of Exchange by having customers test and run production deployments
of pre-release builds of the next version of Exchange. This gives participants
the opportunity to provide real-time design feedback to the Exchange product
development team. Microsoft deployed the first production Exchange 2010
server on April 16, 2007, and in January of 2008 released bits to TAP customers
and partners for review. Shortly thereafter, the authors and other customers
were running Exchange 2010 in their production deployments. When Microsoft
officially shipped Exchange 2010 on November 9, 2009, TAP partners had already
deployed more than 200,000 mailboxes into production! Through this preliminary
process, the authors participated in every step of the final design, gaining valuable
experience with each TAP release for deployment. During this TAP deployment
phase, all TAPs work together with Microsoft to find the best product and best
ways to deploy. Here is what one TAP had to say about this process:
“We have learned a lot through this process, and not only about
Exchange 2010. By interacting with other TAP members and the
product group on a daily basis we have been able to remove the
blinders we sometimes wear from administering the same system
day in and day out. This has allowed us to consider alternate
approaches we could take to improve our system overall and
to identify where some of our own shortcomings are. I’ve seen
things posted I’ve never even thought of before and hope that
our contributions have done the same . . .”
Individually and collectively the authors who wrote this book have been
working with Exchange 2010 for as long as many senior developers at Microsoft.
They have done an awesome job of providing readers with the ins and outs of
the full range of features of Exchange 2010, which will help you get the most
out of the product. Exchange administrators will find the experienced, hands-on
approach of this book invaluable in designing and deploying Exchange 2010.
You wouldn’t want a book that only skimmed and introduced new features.
Fortunately for you, this book is based on the experience of years of successful
deployments in complex environments and a teamwork approach to the final
design process. Microsoft and TAPs have built a product that we are truly proud
of, and this book brings you the right way to walk through it. This book definitely
belongs on the shelf of every serious Exchange administrator and IT manager.
David Espinoza
Senior Program Manager, Exchange Ship Team
Microsoft Corporation
May 2010
love the idea of a best practice book. The initial challenge is to capture the
knowledge of real-life designs and deployments that underpin best practice. The
next challenge is to validate that the claimed best practice is actually valuable.
The final challenge is to focus on a best practice that has enduring value rather
than the tenets that flame into existence sparked by a notion of someone at
a conference or other event and expire just as quickly when everyone realizes that
the proposition being advanced isn’t such a good idea after all. Active Directory
designs for Exchange are an example of best practice that has changed since 1999.
The initial designs for large corporations all seemed to favor the “minimal root
domain and geographic sub-domains” design at a time when we assumed that
a domain was a security boundary and that it was good to segment administration
across sub-domains. Of course, at that time we were influenced by PC LAN
networks and couldn’t quite comprehend how Active Directory would evolve to
accommodate the range of design options that are available and in use today. Of
course, saying what best practice is for Active Directory is another question. The
answer is that there is no best practice, but there are solid guiding principles that
any designer needs to understand and respect before deployment.
I think the same is true for Exchange Server. Best practice is transient and
changes from version to version. It also changes over the lifetime of a version
as the Exchange community comes to grips with the product and understands
the strengths and weaknesses of the software. Microsoft also contributes to
the evolution of best practice by publishing a wealth of information through
Microsoft TechNet and other sites, including the Exchange development group’s
blog. Microsoft also changes best practice as they issue roll-up updates and
service packs to address product flaws and sometimes even introduce new
functionality (and maybe reinforce the old adage that no one should ever deploy
a Microsoft server application until the first service pack is available).
Even though I regard best practice as transient, I still think that it is possible
to set out solid guiding principles that help system designers and administrators
to figure out how to make Exchange work for their organization. Well-organized
books like this render a great service to the Exchange community by laying out
Exchange 2010 in a practical manner that’s based on insight and experience. I
guess this could be called best practice, and that’s certainly what the title says,
but I prefer to think of the knowledge contained here as the guiding principles
that every administrator should be acquainted with before deploying Exchange.
You won’t find a magic bullet here, nor will you find a recipe that you can simply
adopt for a deployment. Instead, the chapters unfold to deliver a comprehensive
guide to Exchange 2010 in an informative and easy-to-follow manner. Even better,
because this book was written well after Exchange 2010 was released, it doesn’t
suffer from the “must be first to market” syndrome that afflicts so many technical
books and leads to guesses and inaccuracies because the book’s content is based
on beta code. And as we all know, beta code isn’t necessarily what is delivered to
I’ve enjoyed reading this book and I think it will be valuable to anyone who
wants to get to know Exchange 2010. Use it to establish your own foundation but
don’t forget that best practice evolves over time so be prepared to evolve your
own knowledge by keeping up to date with developments.
Tony Redmond
Exchange MVP
May 2010
e wanted this book to be something special, something that reflects our
passion and dedication to Microsoft Exchange. Our goal was to write
a book for Exchange geeks by Exchange geeks. We also didn’t want to write
something that fell short of our expectations. To accomplish this lofty goal we
required input, assistance, and support from a long list of people. This may sound
like an award acceptance speech, but it is true. Although only two authors are
named on the cover of this book, without a dedicated group of contributors,
reviewers, and supporters this book would not exist.
First, we want to thank Stanley Riemer for believing in the project and helping
get us the project approved and started. We regret not being able to work with
you on this book and we hope to be able to work with you again soon. We also
would like to thank Andy Schan and Jeffrey Rosen for being able to fill the void
that Stanley left on our project. Without their assistance the project would have
never been completed.
Many other people assisted during this project, but a few people in particular
from the Exchange product group stand out for their support, patience,
and insight—especially as changes were made to the product: Kristian Andaker,
Ed Banti, Matthias Leibmann, Alexander Nikolayev, Greg Taylor, Paul Wimmer,
Gary Cooper, and Brian Desmond.
In addition to these people, we also want to thank the following teams
and companies for their dedicated support and input: everyone on the Microsoft
Exchange 2010 TAP List, Siemens Workplace Architecture Team, the Exchange
administrators at Axel Springer Media AG, and the supportive people at the
Microsoft Enterprise Engineering Center in Redmond.
The three most critical pieces of a successful technical book are its technical
accuracy, its grammatical accuracy, and the support of its editing staff. For
technical accuracy, we were fortunate to have had two of the most thorough
and knowledgeable people in the Exchange server ecosystem to provide technical
guidance for the book: Tony Redmond and Scott Schnoll. They provided candid
reviews that helped improve the content both technically and logistically. This
is a better book thanks to each of them. We also want to thank David Espinoza
and Tony Redmond for their kind words and the keen insight they provided
in the Foreword for this book.
Although it may be shocking to hear, we as authors do not have perfect
grammar, and one of our pet peeves is reading a book with blatant grammatical
errors. Thankfully, we had Becka McKay to help ensure that the book’s
grammatical excellence met the highest standards. She was able to mold our
sometimes narrowly focused word choices and improved not only the way the
book sounds but also its accuracy and clarity.
The support we received from the editorial staff at Microsoft Press has been
unmatched by any of our previous experiences. This book started with Martin DelRe,
the acquisitions editor, bootstrapping the project about a year and a half prior
to its publication. This happened during the final throes of the Exchange 2010
development process, yet he was still able to wrangle some key players in the
Exchange product group to help out. This is a testament both to Martin’s ability
to get things done as well as to the product group’s willingness to assist on this
project. Shortly after we got started, Karen Szall, the book’s developmental editor,
was brought on board. She was critical in helping shape the look and feel of the
book, and she also answered our unending barrage of questions and encouraged
us to start writing. After Karen provided the momentum, we had the privilege
of working with Carol Vu, the book’s project editor. Carol was able to keep track
of multiple versions of each chapter, deadlines whooshing by, and a variety of
other forms of drama all without breaking a sweat. A lesser project editor would
have had a panic attack long ago. We’d also like to thank Christian Holdener for
managing this seemingly unending project and Maureen Johnson for being able
to sift through the pages and pages of technojargon to make an index that is
actually useful to our readers.
We want to extend special thanks to the Exchange product group members
and Exchange experts who spend long hours of their free time reading our
draft chapters to make sure we produced the highest-quality content possible.
We gratefully salute the following people who were part of the review process:
Alessandro Goncalves, Alexander Nikolayev, Andrew Sullivan, Ankur Kothari,
Arno Zwegers, Charlie Chung, Christian Schindler, Colin Lee, Dave Chomas,
David Espinoza, Ed Banti, Erik Szewczyk, Evan Dodds, Gary Cooper, Greg Taylor,
Henrik Walther, Ilse Van Criekinge, Joe Cirillo, John Glynn, Kamal Janardhan,
Korneel Bullens, Kristian Andåker, Kumar Venkateswar, Matthias Leibmann,
Nagesh Mahadev, Paul Wimmer, Ross Smith IV, Steve McIntyre, Thierry Demorre,
Tim McMichael, Todd Hawkins, Todd Luttinen, and Yesim Koman.
Finally, we would like to thank all of the sidebar contributors; these people
really helped add a more comprehensive view of the subject and added depth to
many topics. We’re proud of the number of practical sidebars in the book, and our
thanks go to their creators: Alessandro Goncalves, Alexander Nikolayev, Andreas
Bode, Andreas Essing, Andrew Ehrensing, Ankur Kothari, Arno Zwegers, Brian Day,
Brian Desmond, Carsten Allendoerfer, Charlie Chung, Christian Schindler,
Colin Lee, Devin L. Ganger, Ed Banti, Ed Wilson, Erick Szewczyk, Gary A. Cooper,
Greg Taylor, Henrik Walther, Jeff Mealiffe, Joe Cirillo, John P. Glynn, Jon Webster,
Korneel Bullens, Kristian Andaker, Lars Riehn, Manfred Kornagel, Markus Bellmann,
Matthias Leibmann, Nicolai Wagner, Paul Wimmer, Robin Thomas, Ross Smith IV,
Sascha Schmatz, Steve McIntyre, Thierry Demorre, Todd Hawkins, Todd Luttinen,
Tony Redmond, and Ulf Hansen.
We thank you for taking the time to read our book; we hope that everyone’s
effort comes across and that you find the book both interesting and beneficial.
elcome to Microsoft Exchange Server 2010 Best Practices, a book that was
developed together with the Microsoft Exchange product group to provide
in-depth information about Exchange and best practices based on real-life
experiences with the product in use in different environments. Numerous sidebars
are also included that detail experiences from skilled industry professionals such
as Certified Exchange Masters and Exchange Most Valuable Professionals (MVPs).
The book is largely based on the original version of Exchange Server
2010 released in October 2009 together with information about the changes that
you can expect in Service Pack 1. Because Service Pack 1 was not yet released
when the book was finished, we based our experience in the book on information
available from the Microsoft Exchange product group and on a pre-release build
of Service Pack 1. To make sure we only cover features that will be in the release
of Service Pack 1, we addressed only the most notable changes.
In November of 2008 Joel was updating an Exchange 2007 book when the two
of us began chatting about writing a book on Exchange 2010. Having worked on
several books already, we did not want to write the usual “click-here-and-do-this”
type of Exchange book. We wanted to do something special, something that
reflected our passion for and dedication to Exchange. The idea of working together
along with the Microsoft Exchange 2010 product group to produce a book that
could document years of experience from so many knowledgeable people thrilled
all of us.
From beginning to end, this book took about 17 months to complete, and took
a great deal of effort by a lot of hard-working and intelligent people. We hope
that this effort comes across to you and that you find this book a worthwhile part
of your Exchange library.
Who Is This Book For?
Microsoft Exchange Server 2010 Best Practices is for experienced Messaging
architects, Exchange administrators, support professionals, and engineers,
especially those who are working in medium to large enterprise organizations
and also have at least one year of experience in administering, deploying,
managing, monitoring, upgrading, migrating, and designing Exchange Server.
IT professionals who work in smaller companies also will benefit from the
recommendations and sidebars presented in this book as well as many of the tips
and tricks.
To get the most benefit from this book, prior to reading it you should at least
be able to do the following:
Design and deploy an Exchange messaging enterprise according to
business requirements.
Understand Active Directory concepts, especially how sites and services
provide its essential structure.
Understand the Windows permission model.
Have good experience with the networking protocol TCP/IP v4
and the messaging protocol SMTP.
Understand Windows PKI infrastructures and digital certificates.
You should also understand the basics of Exchange Server 2010, including
the differences between each of the Exchange server roles (experience gained
with Exchange 2007 is valuable here), and you should have experience with using
the Exchange Management Console (EMC) and the Exchange Management
Shell (EMS). The book does not focus on the “how to” and thus does not
include step-by-step guides for each and every setting. This book builds on the
knowledge and experience needed to successfully pass the Microsoft 70-663
exam, Pro: Designing and Deploying Messaging Solutions with Microsoft
Exchange Server 2010.
The target audience for Microsoft Exchange Server 2010 Best Practices
is interested in insights and in looking beyond the common administrative
tasks performed in Exchange 2010 as well as those who want to unveil the full
functionality of the product.
This book is a 300-level technical book; however, the planning and
managing chapter will also be very useful to IT managers seeking guidance
on understanding technical concepts for managing Exchange projects.
How Is This Book Organized?
This book is organized into four parts:
Part I: Preparing for Exchange Server 2010
Part II: Designing Exchange Server 2010
Part III: Upgrading to Exchange 2010
Part IV: Deploying and Managing Exchange Server 2010
The first part of this book consists of three chapters that focus on preparing
your organization for Exchange Server 2010. Chapter 1, “Introducing Exchange
Server 2010,” provides an introduction to Exchange Server 2010, including
high-level information about Exchange and Windows PowerShell. Chapter 2,
“Exchange Deployment Projects,” provides a project-oriented approach to
Exchange Server implementation as well as information about the imaginary
company scenarios that are used throughout the book. Chapter 3, “Exchange
Environmental Considerations,” then provides information about other areas,
such as Active Directory, that you need to consider to have a successful Exchange
The second part of this book considers areas that are required for designing
an Exchange Server 2010 implementation. In Chapter 4, “Client Access in Exchange
2010,” you learn about the Client Access Server role of Exchange 2010. Chapter 5,
“Routing and Transport,” explains how message routing works and how you plan
for the Hub Transport server role. Chapter 6, “Mailbox Services,” considers the
Mailbox server role and explains the database changes introduced in Exchange
2010. Chapter 7, “Edge Transport and Messaging Security,” considers the details
of the Edge Transport server role and, in addition to discussing messaging
security, also covers antivirus and anti-spam functionality. Chapter 8, “Automated
Message Processing, Compliance, and Archiving,” covers the Exchange compliance
and archiving features and also explains how you can perform automated
message processing. Chapter 9, “Unified Messaging,” explains Exchange Unified
Messaging or how to access your mailbox using voice as well as OCS 2007 R2
interoperability with Exchange. Chapter 10, “Federated Sharing,” describes how
to connect two Exchange Organizations using Federated Sharing. Chapter 11,
“Designing High Availability,” introduces you to the concept of Database
Availability Groups (DAGs) and how DAGs can be implemented to provide high
availability for your messaging service as well discussing other availability aspects
such as network load balancing. Chapter 12, “Backup, Restore, and Disaster
Recovery,” takes you through backing up and restoring your Exchange servers,
databases, and features to mitigate the need for restores. Chapter 13, “Hardware
Planning for Exchange Server 2010,” concludes the design part of this book by
providing guidance about hardware planning for your Exchange servers.
The third part of this book consists of Chapter 14, “Transitioning from
Exchange 2003 and Exchange 2007,” which considers how you can approach
the upgrade of your existing Exchange 2003 or Exchange 2007 installation
to Exchange Server 2010 and what important factors you need to consider
The fourth part of this book considers deploying and managing Exchange
Server 2010. Chapter 15, “Preparing for and Deploying Exchange Server 2010,”
describes how to prepare Active Directory and the servers for Exchange 2010,
how you check your environment to make sure all Exchange requirements are
covered, and how you install Exchange 2010 both manually and automatically.
Chapter 16, “Managing Exchange,” discusses how to manage Exchange Server
2010. Finally, Chapter 17, “Operating and Troubleshooting Exchange Server 2010,”
provides information about operating and troubleshooting your Exchange 2010
server environment.
How to Read This Book
This book is written as a reference, and each chapter was written to stand on its
own, so you do not need to read the chapters in order—you can jump between
the chapters that interest you. However, we’d like to point out some chapters that
provide an excellent start and are used for other areas in the book as well.
Almost every chapter in the book uses sample scenarios that are introduced
in detail in Chapter 2. These fictional scenarios are used as real-world examples
and to provide illustrations of how the ideas presented in a chapter could be
implemented in practice. Chapter 3 provides the basis for reading about Exchange
environmental areas such as networks, operating systems, and certificates. We
strongly recommend reading these chapters—they also provide an excellent
overview and best practices around the topic you might want to investigate.
What This Book Is Not
In Microsoft Exchange Server 2010 Best Practices, we assume that you have a good
understanding of Exchange Server 2010 and Windows PowerShell 2.0. For this
reason, this book does not teach the basics of every feature nor does it include
a how-to section for common administrative tasks.
This book is also not a preparation guide for Exam 70-662: TS: Microsoft
Exchange Server 2010, Configuring, or Exam 70-663: Pro: Designing and
Deploying Messaging Solutions with Microsoft Exchange Server 2010, even
though when you apply the knowledge and experience covered in this book,
it will help you to pass these exams.
In general, the book does not include detailed steps for every configuration
setting but tries to provide a foundation so that you can make your own decisions
for what would be optimal in your environment. It does not dictate one specific
way to configure Exchange 2010; instead, it provides the options available and
the factors that should influence your decisions. Thus this book is not a guide
for how to configure your Exchange servers; it is meant to improve your already
configured environment or help you add new features such as Unified Messaging.
System Requirements
This book is designed to be used with the following Exchange 2010 software
Windows Server 2008 or Windows Server 2008 R2
1 GB of RAM
x64 architecture-based computer with Intel or AMD processor that
supports 64 bit
1.2 GB of available disk space
Display monitor capable of 800 × 600 resolution
The following list details the minimum system requirements needed to run
the content in the book’s companion Web site:
Windows XP with the latest service pack installed and the latest updates
from Microsoft Update Service
Display monitor capable of 1024 × 768 resolution
CD-ROM drive
Microsoft Mouse or compatible pointing device
The Companion Web Site
This book features a companion Web site that makes available additional
information to you such as job aids, quick reference guides, and additional
Exchange 2010 resources. We have included these elements to help you plan and
manage your Exchange 2010 organization and apply the book’s recommended
best practices. The companion Web site includes the following:
Job Aids Additional documents on most of the chapters that help you to
collect and structure your work through the book.
Quick Reference Guides Such as the Exchange 2010 Best
Practices Quick Reference Guide, which is an overview of all best
practice recommendations in the book, and the Exchange 2010
Additional Reference Guide, a collection of all Internet links referenced
in the book.
TechNet Exchange 2010 Resources Additional links that might be
useful when reading the book.
You can download these files from the companion Web site, located at
Full documentation of the contents and structure of the companion Web site
can be found in the Readme.txt file in the download.
Support for This Book
Every effort has been made to ensure the accuracy of this book. As corrections
or changes are collected, they will be added to a Microsoft Knowledge Base
article accessible via the Microsoft Help and Support site. Microsoft Press provides
support for books, including instructions for finding Knowledge Base articles,
at the following Web site:
If you have questions regarding the book that are not answered by visiting the
site above or viewing a Knowledge Base article, send them to Microsoft Press via
e-mail to [email protected] Please note that Microsoft software product
support is not offered through these addresses.
We Want to Hear from You
We welcome your feedback about this book. Please share your comments
and ideas via the following short survey:
booksurvey. Your participation will help Microsoft Press create books that better
meet your needs and your standards.
We hope that you will give us detailed feedback via our survey. If
you have questions about our publishing program, upcoming titles, or
Microsoft Press in general, we encourage you to interact with us via Twitter
at For support issues, use only the e-mail
address shown above.
for Exchange
Server 2010
Introducing Exchange Server 2010
Exchange Deployment Projects
Exchange Environmental Considerations
Introducing Exchange
Server 2010
The History of Exchange Server 3
Overview of Exchange Server 2010 14
Exchange Server 2010 Service Pack 1 24
Exchange 2010 Editions and Licensing
Windows PowerShell and Exchange 2010 31
his chapter introduces you to Exchange Server 2010, the most successful messaging
system available today. Because Exchange 2010 is now the third generation of this
messaging product, you will read about what happened in the previous versions and
why—in addition to developing new features and functionality—certain functionality
was abandoned because of changes and evolving customer demands that occurred
over time in the IT landscape.
The overview section introduces several tools that you need to use to manage
Exchange 2010, provides an overview of the Exchange server roles, describes the
functionality that has been removed, the options that exist to mitigate now defunct
functionality, and the difference between Exchange On-Premise and Exchange Online.
This book includes functionality available only with Exchange 2010 Service Pack 1
(SP1), so a section will provide you with an overview of the changes that have been
introduced by SP1 and in what chapters you can read detailed information about them.
Understanding Exchange 2010 editions and licensing, which is important for
planning your organization’s license requirements, is also described, and a Windows
PowerShell 2.0 introduction with some useful cmdlets you need to remember while
reading this book completes the chapter.
The History of Exchange Server
Exchange Server has been in use since 1996, but it did not start with the product
you know today. Exchange Server has changed and evolved quite a lot to reflect
the change in IT since its introduction. In Exchange’s early days, hard disk space was
expensive—thus, single-instance storage was implemented in the Exchange store. Today hard
disk space is cheap and a different technological focus is important.
Throughout the years many Exchange versions have been released, and Table 1-1 provides
an overview of all versions from the first release to Exchange 2010.
TABLE 1-1 Exchange Versions Overview
Exchange 4.0
Spitfire (early 1990’s),
Mercury, Touchdown
March 31, 1996
First generation
Exchange 5.0
February 27, 1997
Exchange 5.5
Osmium or Oz
November 5, 1997
Exchange 2000
Platinum or Pt
July 31, 2000
Exchange 2003
Titanium or Ti
June 30, 2003
Exchange 2007
December 8, 2006
Exchange 2010
October 8, 2009
Second generation
Third generation
The Years Before Exchange
In the early 1990s, many messaging systems were on the market. Messaging systems favored
by large companies, such as Siemens’s MailX, Digital Equipment’s ALL-IN-1, IBM PROFS, and
PC LAN-based systems such as Lotus Notes, Lotus cc:Mail, and Novell GroupWise. The two
standard protocol standards in messaging were X.400 and the Internet standard SMTP. Back
then, X.400 was more common; SMTP was only gaining popularity because of the growth of
the Internet community.
With Microsoft Mail, Microsoft offered a file-based messaging system that stored all
messages in a file share where users accessed their mailboxes using the LAN. A Microsoft Mail
server installation was called a Post Office and it needed a Message Transfer Agent (MTA) to
be able to send messages between Microsoft Mail Post Offices. Limited versions of Microsoft
Mail were also included in Windows 95 and Windows NT 4.0 that excluded the ability to route
messages between Post Offices.
Microsoft Mail made its initial appearance in 1988. At that time, its network stack was
designed for AppleTalk Networks. The last version, Microsoft Mail v3.5, included a multitasking
MTA and was only released because the release of Exchange Server was delayed.
Do you know why the Messaging Application Programming Interface (MAPI) was
developed? The problem was that at the time, Microsoft used different messaging systems:
Internally they used their Xenix Mail System and externally they sold Microsoft Mail. Thus
there was a need to develop a protocol to connect different messaging systems to each
other, and thus MAPI was born. MAPI is actually an API, but many people refer to MAPI as
a protocol the very same way as they refer to POP3. You can find more information about
Introducing Exchange Server 2010
Exchange 4.0 Beta: Codename Touchdown
Andreas Essing
Director Microsoft Services, Siemens AG, Germany
had the first contact with Touchdown (project name of Exchange) in 1994. During
that time, we were actually working on getting a “Microsoft consulting business”
within SIETEC Consulting (a subsidiary of Siemens Nixdorf) up and running. This
approach was not very successful until Microsoft delivered Exchange after two years
of waiting.
Between 1994 and 1996 we had several opportunities to test the software, starting
with TR 2 (the second test release of Touchdown). I remember one phone call
from a Microsoft representative who proudly told me that a message could be
delivered between two Exchange servers. We had computers with 32 MB of main
memory, Windows NT 3.1 Server, and the Exchange client running on Windows NT
Workstation or on Windows for Workgroups 3.11. I still remember the Public folder
Chess Application, an example of how to create an e-mail application using Exchange.
In late 1996, we also had the chance to test the Exchange Web Connector (delivered
on two diskettes). This was the first time we could access the mailbox via a browser.
Outlook was still in development, and the Exchange product group was not very
convinced by Outlook, which was developed by the Office product group at Microsoft.
Exchange Server Before Active Directory
The first generation of Exchange Servers had their own Directory Service integrated in the
product and did not use a directory service provided with the operating system, such as
Active Directory. Exchange 4.0, 5.0, and 5.5 formed this Exchange generation.
Migrating from Microsoft Mail 3.5 to Exchange 4.0
Gary A. Cooper
Senior Systems Architect, Horizons Consulting Inc., United States
began working with Exchange 4.0 early in the beta cycle (I don’t recall the
specific version) at a customer organization. We had moved much of their
organization globally to Microsoft Mail (from nine other e-mail systems) and had tested
Exchange 4.0 in a lab environment for months. However, we did have a significant issue
The History of Exchange Server
(otherwise known as a bug) that we ran into when we deployed Exchange 4.0 RTM
into production. At that multinational company, which had about 90,000 seats,
we deployed the initial Exchange 4.0 servers in each of three regional data centers
and began directory synchronization between them during the Thanksgiving 1996
holiday weekend. Unfortunately, the MTA service would crash after about a third of
the directory sync completed. After internal attempts to troubleshoot the issue, we
opened a support case with Microsoft PSS, who worked around the clock to determine
and resolve the core issue causing the crash. They eventually determined that the
bug was involved in how the MTA service periodically exported the MTA0 readable
file to disk. To get our directory sync completed, two developers came into the office
in Redmond, WA, at two o’clock in the morning on a holiday weekend to build us
a “Buddy Build” of the MTA code DLLs that did not write the MTA0 file to disk, thus
bypassing the bug. Later, we received an official hotfix that resolved the core issue.
Exchange 4.0
Exchange Server 4.0 (codenamed Spitfire, Mercury, and finally Touchdown) was the initial
release of the Exchange Server product and was a X.400-based messaging system including
the first version of the Extensible Storage Engine (ESE) database, a database technology that
was optimized for e-mail including single-instance storage functionality so that messages
were only stored once in a database, even if they existed in multiple mailboxes. Microsoft
saw the need to move away from a file-based messaging system to a database to save disk
space as well as increase performance. Today you can still save approximately 25 percent of
your disk space if you move from a file-based to a database-based messaging system such as
Exchange. However, Microsoft limited the mailbox database size to 16 GB, which later became
a key issue.
To develop Exchange 4.0, Microsoft bought the technology from a few other companies:
X.400 MTA or Transport This part came from a company called DC of Enfield
in the UK. Their code was scattered across literally hundreds of small modules that
collectively formed the X.400 MTA.
X.500 (Directory) This came from a 3Com code base that was originally developed
for Cairo, which was an object-oriented file system that was supposed to be included in
Windows NT 4.0.
Information Store
Microsoft’s original plan for SQL Server was to use a database
called Jet Blue. However, Microsoft bought database technology from Sybase and used it
to develop the SQL product instead. The Exchange team adopted the Jet Blue database,
otherwise known as the Extensible Storage Engine, and has used it ever since.
Exchange 4.0 made its appearance on March 31, 1996—39 months late. Not based on the
same codebase but newly developed from scratch, Exchange 4.0 was the official successor
of Microsoft Mail and thus also continued to use the version numbering. The last version
Introducing Exchange Server 2010
of Microsoft Mail was 3.5, so Exchange Server used 4.0 as its first version. A different story
behind the version number is that Lotus Notes (it was still called Notes and not Lotus Domino
back in those days) had just released their 4.0 version in January 1996 and because of
marketing concerns Exchange Server needed to have an equal version number.
In addition to the mailbox database, Exchange 4.0 included Public Folders, which were
targeted to bring groupware functionality to Exchange and directly compete with the Lotus
Notes replicated database model for applications. Microsoft also provided the 16-bit Visual
Basic–like Electronic Forms Designer to easily and quickly develop form-based applications
that used Public Folders for storage and replication. However, the form-based applications
did not scale as expected in large environments, so many companies did not continue to
develop applications but instead used Public Folders in a basic way to share messages,
calendar information, and contacts.
Exchange 4.0 included an internal, X.500-based directory structure that Microsoft later
used as the foundation for Active Directory. It had a centralized administrator console called
Exchange Administrator (ADMIN.EXE) and also addressed the requirement to support more
users on a single server, which went up to 500 mailboxes.
A basic Exchange 4.0 server hardware back in 1996 was a 486 processor with
66 MHz, 64 MB of memory, and a 4-GB hard disk.
Exchange 4.0 shipped with its own client, Exchange Client 4.0 (code-named Capone client)
and an application for calendaring called Microsoft Schedule+ 7. You can still see the legacy
in the System Public Folder called Schedule + Free/Busy, which includes the free/busy times
for Outlook 2003 clients and before.
The Release of Exchange 4.0 as Experienced in Germany
Lars Riehn
Chief Executive Officer, InfoWAN Datenkommunikation GmbH, Germany
remember the CeBIT computer fair in Germany back in 1996—this was also my
first CeBIT after leaving Microsoft and founding infoWAN. Microsoft released
Exchange 4.0 during CeBIT. Luckily, we had a beta on our demo computers and
could show Exchange live. It was great to get all the visitors wanting to see what
Exchange and e-mail were all about. Yes, in those days we still had to answer
questions like “What is e-mail?”, “Why do I need e-mail?”, and “Will employees
really use e-mail?” These days I am having a déjà vu experience with OCS as the
same argument occurs about its method of communication.
The History of Exchange Server
At that CeBIT, we went to a cocktail reception at the Lotus Notes booth. When I told
people that I started a company purely focused on Microsoft Exchange and related
technologies, everyone thought I was crazy and would go bankrupt in a year. They
were sure Exchange would disappear and Lotus Notes would gain 100 percent of
the market share. Today, infoWAN is still going strong and the success of Exchange
in the market speaks for itself.
I grew up with X.400 as a nice standard for e-mail. At the time, Exchange was still
built around X.400 at the core and X.400 Connectors were the right way to connect
Exchange Servers beyond the LAN. Yes, X.400 was somewhat complex, but I liked it.
And I feel that with X.400 we would have a much smaller problem with spam today.
Here are my favorite longstanding myths for Exchange:
1 . Microsoft will change the Exchange database to use SQL.
2. Microsoft will stop developing new versions of Exchange.
3. Public Folders will disappear.
Exchange 5.0
Exchange Server 5.0, which did not have any codenames, introduced support for
Windows NT 4.0 operating system and support for technologies such as LDAP v2
and SMTP.
For Microsoft, it was obvious that the dominance of the Internet technologies
would keep growing, so they included all sorts of Internet protocols such as SMTP (with
the Internet Mail Connector on a separate disk), NNTP (called Internet News Connector),
and POP3.
This move was initiated when Bill Gates wrote his famous “everything to the Internet”
memo that forced all Microsoft engineering groups to consider how to build Internet support
into their products as quickly as possible. Exchange’s reaction was also to introduce the first
Web-based e-mail client, Exchange Web Access (EWA), which later was renamed Outlook
Web Access and then Outlook Web App (OWA). Exchange 5.0 was released to manufacturing
on February 27, 1997.
Exchange Client 5.0 and Microsoft Schedule+ 7.5 were included as client software but
in mid-1997 Microsoft Outlook 8.0 made its first appearance, combining both clients into
a single program. It was immediately successful.
Introducing Exchange Server 2010
When OWA Was Invented
Tony Redmond
Exchange MVP
he original version of OWA was delivered in Exchange 5.0 after Bill Gates got
the Internet religion. The browser to server communications layer was based on
MAPI and didn’t scale at all, nor did it deliver a tenth of the functionality that exists
in OWA today. As I recall, the “access” part of the name indicated the original belief
that all you would ever want to do is access your mailbox from the Web—all real
work would be done through Outlook.
Exchange 5.5
Exchange 5.5 (codename Osmium or OZ) was released to manufacturing on November 5,
1997, just half a year after the release of Exchange 5.0. Exchange 5.5 implemented support for
symmetric multiprocessing and was available for two different processor generations, Intel
and DEC’s Alpha processor. Even though the Alpha processor was more powerful, the fact
that Exchange was never compiled to take advantage of the Alpha’s 64-bit processor meant
that it was an unpopular platform and never achieved commercial success.
The maximum database size was increased from 16 GB to 16 TB (or as Microsoft called
it back then, the unlimited store), which also brought two Exchange server licenses types:
Standard and Enterprise. Standard had a 16-GB database limitation and Enterprise had 16 TB.
In addition, Exchange 5.5 also introduced support for two-node failover clustering.
The SMTP connector was renamed Internet Mail Service (IMS) and was integrated into the
core Exchange server—there was no need to install extra disks anymore. NNTP was also renamed
to Internet News Service (INS). IMAP4 and LDAP v3 support was added. Other connectors
available in the product were X.400 connector, Site Connector, and Microsoft Mail Connector.
Exchange 5.5 also had a special version: Exchange 5.5 Defense Messaging System (DMS).
This was the same core Exchange 5.5 that relied on X.400 connectors as its basis with a few
registry keys turned on and a specially developed client for the U.S. Department of Defense.
One of the biggest problems of Exchange 5.5 in large environments was the limitation
of having only 202 Exchange sites if you wanted to connect the sites and share a single
Exchange Address Book. My company back then counted roughly 1,000 Exchange 5.5 sites
and thus was not able to connect them together.
Exchange 5.5 was a very robust, trustworthy messaging system. Many companies stayed
on Exchange 5.5 for a long time because they did not see the urgent need to move on.
The Exchange Administrator, as shown in Figure 1-1, was also well understood by most
Exchange administrators. From the client support perspective, Exchange 5.5 fully relied on
Outlook v8.03 as its message client and thus Exchange Client and Schedule+ were abandoned.
The History of Exchange Server
FIGURE 1-1 Exchange Administrator in Exchange 5.5
Exchange Server 2000 and 2003
The second Exchange server generation used Active Directory as its directory service and
extended Exchange’s functionality beyond e-mail by adding Conferencing Services and Instant
Messaging. Exchange Server 2000 and 2003 belong to the second Exchange server generation.
Exchange 2000
Exchange Server 2000 was the first application that fully depended on Microsoft’s new
directory service, Active Directory. Exchange 2000 (codenamed Platinum or Pt) was released
to manufacturing on August 31, 2000, and is version 6.0. It required Windows Server 2000
as the operating system and thus no longer supported Windows NT 4.0. The Exchange
Administrator program was exchanged with the Exchange System Manager (ESM) that was
based on the Microsoft Management Console (MMC) framework.
On the Exchange database level, the concept of Storage Groups was implemented,
providing the functionality to host multiple Mailbox Stores (now called mailbox databases) in
a Storage Group. One Exchange server was now able to host as many as 20 databases. Cluster
support was extended from two to four nodes.
Multiple Public Folder hierarchies were also introduced. Unfortunately, MAPI (the
dominant client protocol) and API did not support more than one hierarchy; thus this feature
was bound to die quickly.
Exchange 2000 moved from an X.400 Message Transport Agent (MTA) to an SMTP MTA.
The SMTP connectors (until then known as IMS) became virtual SMTP servers linked into the
new transport engine. This was a pretty fundamental move for the product.
Introducing Exchange Server 2010
For migration, the Active Directory Connector (ADC) was included that connected
an Exchange 5.5 directory service to Active Directory for smoothly moving users over to
Exchange 2000.
Exchange 2000 also introduced the first Exchange Instant Messaging (later moved to Live
Communication Server, or LCS, which was then renamed to Office Communication Server
2007, or OCS 2007, as it is known today). The Exchange Conferencing Server was another new
feature, but both products were removed from Exchange in the next version.
Right-Click in Exchange System Manager
Tony Redmond
Exchange MVP
n a keynote I delivered at the Microsoft Exchange Conference in 2000, I discussed
the introduction of right-click functionality in the management console. I received
some applause from the 4,000 people in the hall and replied that I wasn’t responsible
for the feature but that “I’d be happy to share the clap with the engineers.” About
two nanoseconds later I realized what I had said and so did the audience, which
dissolved in laughter. For months afterwards, I received messages from engineers in
the Exchange development group who politely inquired about my experience. I can’t
think of how many MPEG clips of my unfortunate comments I received too!
Exchange 2000 also introduced the concept of Administrative Groups and Routing Groups
to separate the scope of administration from the message routing scope. Thus administrators
could provide mail administrators with exactly the right permissions for managing their
servers without interfering with the organization’s routing connectors. However, the
administrative model had some faults that prevented large, dispersed companies that needed
a split-administrative model from rolling out Exchange 2000.
With Routing Groups came the concept of intelligent routing, called Link State updates,
that was used until Exchange 2003. Exchange matured further by using the LocalSystem
account to run its services instead of maintaining its own administration accounts whose
smooth operation could easily be disrupted by simple actions such as passwords expiring.
Exchange 2003
Exchange Server 2003’s first codename was Exchange .NET—it had fallen into the .NET phase
of Microsoft when almost all products had that suffix, but later the codename was changed
to Titanium, or Ti. It was released on June 30, 2003, as version 6.5 and it further built on the
foundation established by Exchange 2000. It was the first Exchange version based on Active
Directory widely accepted by customers; many large companies migrated their Exchange 5.5
environments to Exchange 2003.
The History of Exchange Server
Exchange 2003 ran on Windows 2000 Server or Windows Server 2003. Besides adding
stability and robustness, it introduced a couple of key client access features to Exchange: the
first was the introduction of cached Exchange mode with Outlook 2003 to provide better use
of bandwidth, especially for remote clients; the second was the ability to connect Outlook
clients using RPC over HTTPs to remove the requirement to use VPN connections to access
the Exchange server. Using RCP over HTTPs (later renamed Outlook Anywhere) only requires
an HTTP connection to synchronize e-mail.
In Exchange 2003, the functionality provided by Microsoft Mobile Information Server 2001
and 2002 were integrated into Exchange to provide ActiveSync support for mobile clients—
namely Windows Mobile 5 or later devices directly out of the product. Initially client devices
were configured to sync on a regular schedule with the option of SMS notification for new
messages (also known as AUTDv1). The “push-mail” feature using DirectPush technology (also
known as AUTDv2) was implemented with Exchange 2003 Service Pack 2.
Exchange 2003 Service Pack 2 also introduced a new database size limit of 75 GB,
even in the Standard Edition of Exchange. The maximum database size limit in Enterprise
remained 16 TB.
Anti-spam and antivirus protection was gaining awareness, so Exchange 2003 SP1
introduced the Intelligent Messaging Filter (IMF) to scan and reject spam messages. A more
sophisticated anti-virus API was also added to provide a better foundation for third-party
antivirus solutions to protect the system. Figure 1-2 illustrates the Exchange System Manager
that was used to manage Exchange in Exchange Server 2003.
FIGURE 1-2 Exchange System Manager in Exchange 2003
Introducing Exchange Server 2010
Exchange Server 2007 and Beyond
Exchange Server 2007 can be seen as the third generation of Exchange server. It was rebuilt
from the ground up, and not only required a 64-bit processor architecture, but was also the
first version of Exchange in which the Exchange Management Console (EMC)—successor of
the Exchange System Manager—no longer included all configuration options. Configuring
many of the advanced configuration options required Windows PowerShell.
Windows PowerShell in and of itself was the biggest step from moving to Exchange 2007.
Exchange administrators were required to learn some scripting before they could use
Windows PowerShell. However, it soon became one of the major success factors because
administrators could automate administrative tasks quickly and easily. The Exchange
Management Console was based on Windows PowerShell, which is still the case in Exchange
2010. Every option you select in the EMC triggers an associated Windows PowerShell cmdlet
in the background.
Exchange 2007 also introduced five server roles: Mailbox, Client Access Server, Hub
Transport, Edge Transport, and Unified Messaging. Specialized Exchange server roles can be
added and removed when needed and also install only the code that is needed for whatever
server roles run on a computer, not everything as required by previous Exchange versions.
Exchange 2007 changed again the concept of message routing and removed Routing Groups
to rely fully on the Active Directory site model and use Active Directory sites and site links for
internal routing purposes. The X.400 Connector was retired, and storage groups were modified
to support continuous replication. Up to 50 databases could be created on a single server.
From the failover clustering perspective, Exchange 2007 added log file shipping technology
and laid the foundation for the Database Availability Group functionality in Exchange 2010.
Thus, in addition to implementing the traditional single-copy cluster (SCC) that required
a shared disk, such as that provided by a storage area network (SAN) system, it also supported
cluster continuous replication (CCR) and local continuous replication (LCR) as a means to
provide failover clustering with replicating transaction log data to be replayed to update
a database copy on another server (CCR) or disk (LCR). Exchange 2007 SP1 introduced standby
continuous replication (SCR) to replicate a message database to a remote Exchange server.
Exchange 2007 de-emphasized Public Folders by removing their support from the EMC
with the original version, but because of customer feedback they implemented Public Folder
management back in a separate console launched from the EMC toolbox with Exchange 2007
SP1. Exchange 2007 also laid the basis to move away from Public Folders by implementing
Autodiscovery and Availability service used by Outlook 2007 and later clients.
Bringing voice to the mailbox was another change that Microsoft implemented into the
core of Exchange 2007. The Unified Messaging server role was added to provide users with
the ability to access their mailboxes using voice and also served as a voice mail system for
Office Communication Server 2007 R2.
From the client perspective, for the first time in Exchange history Exchange Server 2007
no longer included a message client apart from the OWA.
The History of Exchange Server
Overview of Exchange Server 2010
Exchange Server 2010 is one of the most functional messaging systems on the market,
and the most popular messaging system used in organizations. To maintain competitiveness
and to continue the development of technology began in Exchange 2007, Exchange 2010
brought several new features and functionality to the market.
Management Consoles
Exchange 2010 includes a couple of management consoles that help you to perform
administrative tasks or manage Exchange’s configuration.
Exchange Management Console
The EMC is the main administrative console for configuring and managing Exchange, as
shown in Figure 1-3. It shows the most important settings of the Exchange configuration
and allows you to modify them if you have permissions.
The EMC includes the following main areas that help you to manage Exchange:
Exchange Configuration Includes organization-wide configuration that applies
not only to a single Exchange server but can also affect all servers. For example you
configure Database Availability Groups (DAGs) and mailbox databases are configured
on this level.
Server Configuration Allows you to view and modify server-based settings that
apply only to an individual server—such as server-specific OWA or POP3 settings—or
assign a Dial-Plan to a Unified Messaging server.
Introducing Exchange Server 2010
Recipient Configuration Here you do all recipient-related tasks such as enabling
a mailbox or creating a distribution list or a contact.
Toolbox Includes various tools that help you to configure, monitor, and troubleshoot
your Exchange organization, such as Queue Viewer and Best Practices Analyzer.
The Show Exchange Management Shell command button is a very useful but not widely
known improvement to the EMC in Exchange 2010. It is located in the bottom-left corner
of the dialog boxes used to reveal and set properties on Exchange objects, as shown in
Figure 1-4. When you click this button a window opens, showing the Windows PowerShell
command that Exchange will execute when you click OK or Apply.
FIGURE 1-4 Show EMS command button
As a best practice it is recommended that you take a look at the cmdlets that are
executed in EMC quite frequently at the beginning to familiarize yourself with the syntax
and to remember the cmdlet when you need it in EMS.
Another tool new to the EMC in Exchange 2010 is the Exchange Management Shell Command
Log, which records all shell commands that you run in EMC. As shown in Figure 1-5, you can
start command logging, which provides you with detailed information about the commands
that you’ve run. You also have the option of exporting the commands to a CSV file.
Overview of Exchange Server 2010
FIGURE 1-5 View Exchange Management Shell Command Log
You can access the View Exchange Management Command Log by right-clicking an object
such as Mailbox in the left pane of EMC and then clicking View and selecting View Exchange
Management Log.
Exchange Management Shell
The EMS is a task-based, tailored command-line shell on top of the Windows PowerShell
scripting language that can ease the way you do administration.
Using the EMS, as shown in Figure 1-6, you can perform every task that can be done in the
EMC and additional tasks that are not available in EMC such as configuring the port of a POP3
All of your Exchange administrators should be trained to understand the basics of the
EMS and how to create batch scripts that ease their daily business lives. Although EMS will be
used mainly by administrators, any Exchange user who is enabled for PowerShell (the default
Introducing Exchange Server 2010
setting) can use EMS, provided that she has access to a workstation that has EMS installed.
Role-Based Access Control (RBAC) limits the set of cmdlets that a user can see or run to those
included in the role(s) assigned to the user.
Some cmdlets require elevated permissions, so if you’re not working with
the administrator account but with a normal user account it is a best practice to start EMS
with Run As Administrator.
Exchange Control Panel
With the Exchange Control Panel (ECP), Exchange 2010 now provides a Web-based
management console that can be used by administrators and end users to perform
common management tasks for Exchange 2010. ECP uses the RBAC permissions model of
Exchange 2010; thus you can only see the functionality that you have permissions to access.
It can be accessed using the URL https://<CASserver>/ECP, OWA, or from Outlook 2010
and opens in the Web browser as shown in Figure 1-7.
FIGURE 1-7 Exchange Control Panel
Overview of Exchange Server 2010
In ECP you can perform several User & Groups–related tasks, such as modifying mailbox
properties and creating distribution groups now called public groups. You can configure Mail
Controls such as Transport or Journal Rules, you can perform Reporting tasks such as searching
Delivery Reports and view or export Auditing Reports, and you can perform Phone & Voice–
related tasks such as quarantining a device and configuring an ActiveSync Policy.
You can find more information about the ECP in Chapter 4, “Client Access in Exchange 2010.”
A new functionality in Exchange 2010 SP1 is that you do not need
a mailbox-enabled account to be able to use ECP. This is a particularly helpful change
in environments where you use separate accounts for administrative tasks.
Exchange Server Roles
Exchange 2010 is quite a massive product that includes many facets of messaging included
in a single product. It includes a sophisticated messaging routing engine that is capable of
processing very large volumes of e-mail while applying anti-spam, antivirus, and compliance
checks; it supports a very wide range of client protocols from the simple, such as POP3, to
the highly functional, such as MAPI; and it accommodates varying hardware designs from
a simple multi-role server to designs based on the new Database Availability Group (DAG)
feature to deliver high availability.
Including all the functionality in a single product would just blow the requirements on
hardware, so Microsoft implemented server roles, allowing you to choose to install only the
roles you require. Figure 1-8 shows all available Exchange Server roles.
- Routing
- Policy
- Spam/Anti-Virus
Edge Transport
- Routing
- Policy
Hub Transport - SMTP
- Voice Messages
- Outlook Voice Access
Client Access
- RPC Client Access
- Web Services
- Active Sync
FIGURE 1-8 Exchange 2010 Server Roles Overview
Introducing Exchange Server 2010
Mailbox Unified Messaging
- Mailboxes
- Public Folders
PBX/Telephone Carrier
The Client Access Server role is responsible for serving client connections: Outlook, OWA,
Outlook Anywhere, Exchange ActiveSync, Exchange Web Services (EWS), and POP3 and
IMAP4 protocols. It pipelines end user–based communication to mailbox server role and
is responsible for additional services such as Autodiscover, availability, and Exchange Web
Services (EWS). Chapter 4 provides an in-depth overview of the Client Access Server role.
Mailbox databases—and thus the mailbox data—are stored on the Mailbox server role.
The public folder database is also on the Mailbox server role. The mailbox role includes DAGs
to make the server role fault-tolerant. You’ll find more information about the Mailbox role in
Chapter 6, “Mailbox Services.”
All message routing is done by the Hub Transport server role, which is responsible for
delivering messages to the correct destination mailbox server and routing messages to the
perimeter outside such as the Internet. Chapter 5, “Routing and Transport,” provides you with
the necessary information about the Hub Transport role.
Similar to the Hub Transport, the Edge Transport server role is also responsible for
messaging routing purposes, but is a special server role that can be placed in a perimeter
zone to send and receive messages from the Internet. Because of this situation, it also
includes anti-spam and antivirus functionality to protect your internal environment. You
can get more information about the Edge Transport role in Chapter 7, “Edge Transport and
Messaging Security.”
The Unified Messaging (UM) server role combines voice and e-mail messaging in the
Exchange Server store, and it integrates telephony networks into Exchange. This role allows
you to use Exchange as your voice mail system for your OCS 2007 R2 implementation.
Chapter 9, “Unified Messaging,” includes all information about the UM role.
One of the best Exchange 2010 resources available for understanding all
Exchange roles including the features is the Exchange 2010 Architecture Poster, which
is scheduled for public availability in August 2010 at
?linkid=9729251. You should definitely have a copy of it pinned to the wall in your
working environment where you can review the details daily.
Feature Changes from Exchange 2003 and 2007
As with every new version of software, features and functionality of previous versions will
be retired. As technology continuously advances and changes, the Microsoft product group
has to balance adding new functionality, maintaining existing functionality, and removing
outdated functionality for Exchange 2010.
Of course, you can retain Exchange 2003 or 2007 functionality by keeping a legacy
Exchange server to use only for that functionality, but it’s always an in-between step.
Therefore, if you’re currently running Exchange 2003 or 2007 it is important to clearly
understand your current messaging environment in terms of used features and what
protocols your applications use. This will prevent you from unpleasant surprises such as
an application that stops working because you moved the mailbox to Exchange 2010.
Overview of Exchange Server 2010
Table 1-2 lists all Exchange 2003 features that are no longer available and explains their
replacement functionality available in Exchange 2010.
TABLE 1-2 Replaced and Retired Features of Exchange 2003
Administrative groups
RBAC permission model.
Routing groups
Active Directory site-based routing model.
Link state routing
Recovery storage group
Recovery database.
Routing objects
No replacement.
Event service
Intelligent Message Filter
Anti-spam agents available in Edge or Hub
Microsoft Exchange Connector for
Novell GroupWise and migration tools
No replacement—use a third-party
migration tool for migration.
Microsoft Exchange Connector for
Lotus Notes
Network News Transfer Protocol (NNTP)
No replacement.
X.400 message transfer agent (MTA)
Exchange Installable File System (ExIFS)
Exchange extensions in Active Directory
Users and Computers (ADUC)
Recipient management is exclusive to
EMC or Windows PowerShell.
Exchange Server Mailbox Merge wizard
Clean Mailbox tool
Use the Export-Mailbox cmdlet in
Exchange 2010 RTM or the NewMailboxExportRequest cmdlet in SP1.
Exchange Profile Redirector tool (ExProfRe)
No replacement.
Recipient Update Service
No separate service available; use EMS
for the same functionality.
Monitoring and status node
Exchange 2010 Management Pack
for SCOM.
Message Tracking Center
Use Message Tracking or Tracking Log
Explorer tools.
Mailbox Recovery Center
Use the Restore-Mailbox cmdlet.
Mailbox Management Service
Retention Policies or Messaging records
management (MRM).
Migration Wizard
Use the Local Move Request and Remove
Move Request wizards.
Introducing Exchange Server 2010
Non-MAPI top-level hierarchies in a public
folder store
No replacement.
NNTP access to Public folders
IMAP4 access to Public folders
CDO 1.2.1
Protocols no longer available; use
EWS or EWS Managed API.
Exchange WebDAV
Store events
Even though Exchange 2007 looks very similar to Exchange 2010, there have been quite
a few changes, as listed in Table 1-3.
TABLE 1-3 Replaced and Retired Features of Exchange 2007
Cluster continuous replication (CCR)
Database availability groups (DAGs).
Standby continuous replication (SCR)
Single copy cluster (SCC)
Local continuous replication (LCR)
No replacement.
Storage groups
Every database has its own set of transaction logs.
Extensible Storage Engine (ESE)
streaming backup APIs
VSS plug-in for Windows Server Backup.
RPC Client Access and Address Book service.
Exchange WebDAV
Protocols no longer available; use EWS
or EWS Managed API.
Move-Mailbox cmdlet
Use Local Move Request and Remove Move
Request wizards.
Setup /recoverCMS
Setup /m:RecoverServer.
OWA Document access
No replacement.
OWA Web Parts
Not implemented in Exchange 2010 RTM, again
available with Exchange 2010 SP1.
Microsoft Transporter Suite for Lotus
Domino or IMAP/POP3 migration
No replacement—use third-party migration tool
for migration.
Exchange UM Test Phone
Can still be used with Exchange 2010 RTM,
but must be replaced in SP1 with the UM
Troubleshooting Tool.
Overview of Exchange Server 2010
If your company requires the preservation of specific features or functionalities
of legacy Exchange versions, you should plan to keep an Exchange server of the required
version in operation to ensure continued access to the functionality. However, you should
not underestimate the additional effort this creates, such as the need to migrate in
a two-step approach from Lotus Domino to Exchange 2007 and then to Exchange 2010.
Exchange On-Premise versus Exchange Online
A traditional Exchange installation requires hardware that is placed in your datacenters,
the purchase of software licenses so that the product is allowed to run, and administrators
that manage the servers. For some time there has been a push for on-demand service
provisioning, where users only pay for the service they use, not for the complete cost basis
to establish and deliver the service.
In early 2006, Microsoft introduced the idea of Software as a Service (SaaS) to provide
application services on-demand and called their in-the-cloud messaging service Exchange
Online. To distinguish between Exchange Online and the installation you run in your own
company, Exchange 2010 uses the term Exchange On-Premise (or on-prem) because the
servers run on your premises. Today’s version of Exchange Online is based on Exchange 2010.
The two service options available for Exchange differ in the following ways:
Exchange On-Premises This version is generally dedicated to the customer,
Exchange servers are placed in a datacenter for the customer (on the customer’s
premises), and licensing is a fixed price including both hardware and software licensing.
Exchange Online This service is provided as multi-tenant or hosting service,
generalized and highly standardized for many customers. Licensing is on-demand,
meaning that you pay only for the mailboxes you use. The Exchange servers are placed in
a common datacenter and you connect to it over the Internet using a secure connection.
Microsoft provides Exchange Online service as part of the Business Productivity Online
Services (BPOS) line.
Exchange Server 2010 is the first version of Exchange that provides a real hybrid approach
to Exchange Online services. It was fully designed to allow you to host your sensitive users
on-premises and move the rest to the cloud, or in this case, to Exchange Online. Coexistence
between the users is achieved by Exchange 2010’s new feature, Federation Service, which
allows sharing mailbox information such as free/busy times with another company, as shown
in Figure 1-9.
All Exchange 2010 Management Consoles such as EMC are capable of managing both
an on-premises and an online setup. Thus, running an Exchange organization that operates
as a hybrid service can be a real option for your company to reduce the costs of mailboxes.
Features include moving mailboxes from on-premises to Exchange Online while the user of the
mailbox is logged in and on a scheduled basis, as well as the ECP, which supports self-service
control for users. Of course, Microsoft is not the only company that delivers hosted Exchange
2010. Some companies have hosted Exchange for 10 years or more and have much experience
Introducing Exchange Server 2010
FIGURE 1-9 Exchange 2010 in a hybrid environment
in this space. The difference to Exchange Online is that the Microsoft develops a product to
operate as smoothly in a hosted environment as it does in an on-premises deployment.
This book focuses on Exchange On-Premises, but Chapter 10, “Federated Sharing,”
provides information on how to connect another Exchange organization to your Exchange
environment, including information on how to connect Exchange to Exchange Online.
For more information about Exchange Online, see
Europe’s Issues with Exchange Online
Manfred Kornagel
Principal Consultant, Siemens AG, Germany
xchange Online offers you full integration in an existing Exchange System and
greatly reduces the operating costs for your messaging system, especially in the
areas of administration, maintenance, and upgrade. On the other hand, you have to
make sure that the link between your offices and Exchange Online is redundant so
that network problems will not interfere with your messaging system.
One of the most critical areas I see currently in Europe is security. Because
Exchange Online hosts the mailboxes in centralized datacenters throughout
Europe, one in Dublin and one in Amsterdam, the county’s laws might not allow
storing company-related data in a foreign country. This is the situation as of 2010;
remember that Microsoft may have other datacenters in place in Europe in the
coming years. It can also be company policy not to store any sensitive data outside
the company, which would prevent migrating fully to Exchange Online.
However, the big opportunity I see here is with regard to hybrid implementations,
in which you mix Exchange 2010 and Exchange Online. You move your non-critical
mailboxes to the cloud and keep your important or business-critical mailboxes
Overview of Exchange Server 2010
Exchange Server 2010 Service Pack 1
Exchange Server 2010 Service Pack 1 (SP1) is scheduled to be released in third quarter 2010.
Traditionally, service packs have been bug fixes and security updates. Of course, SP1 still
includes all Exchange 2010 RTM Update Rollups and several other bug fixes, but also includes
additional functionality and some new features.
SP1 also comes with a schema update that requires you to plan the update accordingly.
Table 1-4 provides an overview of what is newly added by SP1 and in which chapter of this
book you can find more information.
TABLE 1-4 Exchange 2010 Service Pack 1 New Features
Schema and Domain Update
Chapter 3
SP1 requires you to update the Active Directory schema and every
Outlook Web App (OWA)
Outlook UI includes improvements with the goal of better user
experience on different screen sizes, such as on netbooks.
Outlook Themes allow you to select different layout styles for OWA.
Calendar print allows you to select a calendar view and print it
Support adding inline images while composing new e-mail.
Long-running operations do not block user experience.
Auto-save drafts while composing new e-mail.
Exchange Control Panel (ECP)
Accounts used no longer need to be mailbox-enabled.
RBAC management has been improved.
Calendar sharing permission management for the end user is included.
Create and configure transport and journaling rules.
Manage Exchange ActiveSync Policies and ActiveSync Access Settings.
Manage quarantined devices and Device Access Rules.
Manage RBAC Roles Groups and User Roles (covered in more detail
in Chapter 16).
Create and manage resource mailboxes and security groups.
Create and manage Allow/Block/Quarantine policies.
Exchange Web Services (EWS)
Includes support for certificate authentication.
Introducing Exchange Server 2010
Chapter 4
RPC Client Access
Includes enhanced monitoring and diagnostic tools.
Supports cross-premises and datacenter scenarios.
Can now be turned on/off.
Includes delay throttling for users.
Protects CAS and Active Directory from being overwhelmed
by a single user.
Includes enhanced monitoring.
Exchange ActiveSync (EAS)
Photos are not only available from local contracts, but also from
GALs. They are also cached locally and thus available offline.
Enhanced EAS throttling support such as configure that a user
can only connect a single device.
Block/Quarantine notification to mobile device.
Includes Simple Rights Management Messaging.
Chapter 5
Delivery Class Throttling
Classifies a message based on certain characteristics and assigns it
a delivery class. Throttling will investigate messages when they are
sent by individual users and add a cost to each message based on
message size, number of recipients, and frequency. This cost factor
allows assigning a delivery class to the messages.
Log growth monitoring
Chapter 6
Monitor and track how quickly the log is growing.
No changes to Edge Transport, anti-spam, and antivirus in SP1
Chapter 7
Discovery Search
Chapter 8
Includes improved discovery search functionality such as being able
to view the size of a search before adding it to the discovery search
Archive Mailbox
Archive mailboxes can be in any database in the organization. You
can move the archive mailboxes to a desired database.
Move archive mailboxes between Exchange organizations and
cross-premises, such as Exchange Online.
Outlook 2007 also supports archive mailboxes (requires Outlook
2007 security update released in Q3/2010).
Exchange Server 2010 Service Pack 1
Managed Folders
De-emphasized in Exchange Server 2010 and only managed through
EMS in SP1 (not available in EMC in SP1).
Retention Policy, or MRM 2.0
You can use the EMC GUI to configure and manage retention
polices and retention tags; in RTM, you could only manage these
via Windows PowerShell.
IRM-enabled Active Sync SP1 Builds IRM into ActiveSync,
allowing non-Windows Mobile EAS clients to protect and consume
IRM-protected content.
RMS support for Web-ready document view SP1 provides the
ability to access attachments that are IRM-protected using Web
Ready Document Viewing.
Unified Messaging
More OVA configuration settings are available in ECP, such as choice
of ordering.
Calls Name Display support if your PBX provides caller names to UM.
UM users can belong to two UM Dial Plans.
Voicemail Preview includes more languages such as European Spanish
and was increased in accuracy.
New UM Troubleshooting Tool is based on the TestExchangeUMCallFlow cmdlet to test UM connectivity.
UM Reporting includes Call Statistics and User Call Logs reports
that no longer require SCOM 2007 but are accessible from ECP.
Mailbox move from Exchange 2007 or cross-premises includes UM
Dial Plan move.
Chapter 9
Instant messaging integration in OWA
Instant messaging integration is no longer configured in the
web.config file but uses the Set-OwaVirtualDirectory cmdlet.
OWA now supports alerts such as instant messaging invites.
No changes to Federation in SP1
Chapter 10
Database Availability Groups (DAGs)
Chapter 11
Static IP for DAGs.
Granular replication.
Failover performance improvements.
Support for a two-node DAG in Datacenter Activation Coordination
Introducing Exchange Server 2010
Outlook cross-site database failover experience such as being able to
enable or disable cross-site direct connect.
Additional scripts such as a script to distribute active database copies
across servers.
Faster failovers with improved post-failover client experience.
No changes to Backup and Restore in SP1
Chapter 12
Performance and Scalability planning
Chapter 13
Capacity Planning and Performance Reporting Toolkit.
EPA for 2010.
Chapter 14
Move Mailbox
Improvement such as converting mailboxes to/from linked mailbox,
archive, cross-forest support, and so on.
Chapter 15
All software requirements can be installed automatically.
Support to implement split permissions.
Chapter 16
Active Sync
Manage Active Sync devices using ECP.
Group Management
Naming Policy for group naming restrictions Manage Security
Groups using ECP.
Hide Groups from GAL using ECP.
Define a default OU for group creation.
Ability to configure Hierarchical Address Books (HABs).
Role-Based Access Control (RBAC)
Split permissions between Domain administrators and Exchange
administrators so an Exchange admin is not able to grant itself
Domain Admin rights.
Support for scoping based on database level.
Manage RBAC Roles Groups and User Roles with ECP.
New-MailboxExportRequest cmdlet
Uses an internal PST writer library and thus doesn’t require Outlook
to be installed on any Exchange server as the Export-Mailbox cmdlet
required. Follows the asynchronous model of mailbox moves: you place
a request and it will be processed by MRS that writes a PST file.
Replaces the Export-Mailbox cmdlet.
Exchange Server 2010 Service Pack 1
Public Folder Troubleshooting
Chapter 17
Repair Public Folder database cmdlets.
Message Tracking
Cross-premises message tracking.
Client Access Server Troubleshooting
Reset Client Access Server virtual directory.
Mail flow monitoring
Cross-premises mail flow monitoring functionality.
Exchange 2010 Editions and Licensing
An area that is often underestimated but also important when planning your Exchange
server deployments is which editions of Exchange Server 2010 you will use and what
type of licenses you will buy for your users. This topic is especially important because
planning thoroughly can save you money.
The most common license types are Server Editions and Client Access Licenses (CALs).
However, in Exchange 2010 you can also purchase an Exchange 2010 External Connector
License, which allows an unlimited number of clients to access an Exchange server in
scenarios where the number of CALs is uncertain. This type is limited to non-employees
such as partners or suppliers.
You can access more information about licensing for Exchange Server 2010
(on-premises) at
Exchange Server 2010 Editions
As in previous Exchange versions, two server editions are available: Standard and
Enterprise. Both editions are licensed by a product key, which mean you can switch
a Standard edition to an Enterprise edition when you enter a valid license
product key.
Although the Exchange Server 2010 Standard edition is targeted for smaller companies,
it also can be used for specific server roles such as Hub Transport or Unified Messaging
server roles, as well as in small branch offices. The Enterprise edition supports up to
100 mounted databases at the same time and thus is targeted to large companies.
Table 1-5 provides an overview of each edition’s offerings.
Introducing Exchange Server 2010
TABLE 1-5 Exchange Server 2010 Edition Offerings
Mounted Mailbox Databases
Maximum 5 databases
Maximum 100 databases
Passive Database Copies
257 databases
257 databases
Database Size Limit
16 TB
16 TB
Default Database Size Limit
1 TB but can
be changed with
registry key
16 TB (16,000 GB)
Database Availability Groups
(requires Windows Server
2008 Enterprise edition)
Included (limited by
mounted databases)
Unified Messaging
The major difference between the Standard edition and the Enterprise edition is the
number of mounted mailbox databases on that server. You also can create DAGs with an
Exchange 2010 Standard edition, but remember that you need a Windows Server 2008
Enterprise edition as an operating system to get the cluster features needed for DAGs.
As a guideline, you can use Standard editions for all server roles and you need only
to plan for Enterprise editions at mailbox servers that will have more than five databases
mounted at the same time. This licensing model allows you also to start with a Standard
edition, and when you require it purchase an Enterprise edition.
If you ever wondered what happens when the trial edition expires in Exchange 2010,
the quick answer is nothing, except that you will see some extra nag screens to remind
you that your Exchange servers need to be licensed. You will stay on your Standard edition
license and the expiration of the trial edition will have no functional impact. However,
remember that you will not get any support from Microsoft for a trial edition.
Exchange Server 2010 Client Access Licenses
Exchange Server 2010 comes with two CAL editions that are also called Standard and
Enterprise. The difference from the server editions is that the CAL is an additive license, so
you always need to buy a Standard CAL and then add an Enterprise CAL to gain advanced
functionality, such as voice mail.
Both CAL editions can run against either server edition; thus, a Standard CAL can run
against an Enterprise edition server and vice versa. Table 1-6 shows an overview of what each
CAL edition offers.
Exchange 2010 Editions and Licensing
TABLE 1-6 Exchange Server 2010 Client Access Licenses
E-mail, shared calendaring,
contacts, tasks
Advanced Active Sync Policies
Journaling on per-user or
per-distribution list basis
(per database
Unified Messaging (voice mail,
for example)
Custom Retention Policies
Archive Mailbox
Multi-Mailbox Search and
Legal Hold
Information Protection
and Control (IPC): journal
decryption, transport
protection rules, Outlook
protection rules, IRM Search
Advanced anti-spam including
Forefront Protection 2010 for
Exchange Server
If you’re planning on using Information Rights Management features of
Exchange 2010, you need to purchase additional Windows 2008 Rights Management
Server (RMS) CALs for each user or device that uses it!
Exchange Organizational Health
EMC includes an option to generate an Organizational Health report to provide an overview
of your Exchange organization including licensing information as well as a summary of the
Exchange servers and recipients. You can use this information to verify that your Exchange
Editions and Licenses are purchased correctly. Figure 1-10 shows a sample report.
Organizational Health scans the following sets of users to determine the CAL calculation:
Unified Messaging Users
Managed Custom Folder Users
Advanced ActiveSync Policy Users
Archived Mailbox Users
Retention Policy Users
Searchable Users
Journaling Users
Introducing Exchange Server 2010
FIGURE 1-10 Viewing Organizational Health in EMC
Windows PowerShell and Exchange 2010
One of the biggest changes since the move to Active Directory in Exchange 2000 was the
move to Windows PowerShell as the basis for automating management tasks in Exchange
2007. Windows PowerShell is a command-line interface created to provide a scriptable and
programmable management interface.
Building on the success of Exchange 2007 and Windows PowerShell, Exchange 2010
integrates tightly with Windows PowerShell 2.0 and Windows Remote Management 3.0
(WinRM) to create a Roles-Based Access Control system that provides a secure and scalable
scripting solution. WinRM provides an implementation of WS-Management (WSMan). It
allows for remote management by listening for management connections using IIS primarily
on TCP/IP port 80. By default, communication is only allowed when it is encrypted using the
Negotiate or Kerberos Security Service Provider.
The Role-Based Access Control (RBAC) security is a feature built upon Windows
PowerShell 2.0. This allows a role to be created and then used to filter the cmdlets
and parameters that are available for viewing and executing.
RBAC in Windows PowerShell 2.0 allows you only to see the cmdlets you have
permissions for. For example, even though you are member of the Organizational
Management role group, you cannot see the New-MailboxExportRequest cmdlet, which
requires the Mailbox Import Export role.
Windows PowerShell and Exchange 2010
In Exchange 2007 the Windows PowerShell runspace and the Exchange snap-in have
to be installed on the management workstation and also require full RPC connectivity to
the managed Exchange servers. This proved problematic in complex domain and network
environments. This also required that every management station needed the Exchange
binaries installed and maintained anytime updates were released. As mentioned earlier, with
Exchange 2010 and Windows PowerShell 2.0 all administrative communication is now handled
over TCP/IP port 80 or 443 and not over random RPC TCP/IP ports. Because these ports are
commonly open to provide access to the Internet, this provides encrypted communications
more easily through a firewall.
Although the Exchange 2007 management framework brought many great functions
with Windows PowerShell, it had a number of deficiencies. In the EMS in Exchange 2007
the cmdlets execute on the server it was run on. Therefore you had no ability to throttle
or control the resources that these cmdlets would consume. In Windows PowerShell 2.0
communication is handled through WSMan, which provides the ability to throttle connections
to reduce the likelihood that an administrator can negatively impact client performance by
performing too many administrative tasks against the Exchange server.
When you remotely connect to an Exchange server, you do not immediately see
which server you’re connected to. To determine which Exchange server you’re connected
to, use the Get-PSSession | fl ComputerName cmdlet.
The main difference between Exchange 2007 with Windows PowerShell 1.0 and Exchange
2010 with Windows PowerShell 2.0 is that the Exchange snap-in is not loaded locally when
you open the EMS. Instead, Windows PowerShell connects to the closest Exchange 2010
server using WinRM, performs authentication checks, and then creates a remote session for
you. Figure 1-11 shows the process used for logging into EMS in Exchange 2010.
Nego (2)
AuthZ Module
Powershell Client
PowerShell (5a)
AuthZ Module
Internet Information Services (IIS)
FIGURE 1-11 EMS Process
Introducing Exchange Server 2010
Active Directory
When you run EMS, the following process happens in the background before you can
use it:
When EMS is opened a new remote Windows PowerShell session is established with IIS
on the remote server. IIS will authenticate the user at this time.
The WSMan virtual directory (or Windows PowerShell vdir) is contacted on the server
and given the authenticated user’s information.
The Exchange RBAC Unmanaged Authorization module is contacted to verify that
the logon process can continue. It then contacts Active Directory to authorize the
user. If successful, WSMan is instructed to continue the process. If authorization is
unsuccessful, WSMan is instructed to terminate the process.
WSMan passes the user principal information to the Windows PowerShell fan-in
provider. A fan-in provider allows many connections to a single service. The PowerShell
Fan-in provider allows IIS to call Windows PowerShell.
Windows PowerShell hands off the user principal information to the registered
authorization module (the Exchange RBAC Managed Authorization module), which
analyzes the connecting user’s RBAC definitions against Active Directory, and then
builds the initial session state for handoff back to Windows PowerShell. The initial
session state contains the cmdlets and parameters that will be exposed to the
connecting user.
The Exchange RBAC Managed Authorization Modules sends this information back to
Windows PowerShell via their initial session state interfaces.
A client runspace is created on the server within the IIS worker process and PowerShell
configures implicit remoting proxies to be handed back to the client.
The runspace is returned and imported using the Import-PSSession operation on
the client.
If you have the Exchange Management tools installed, you can attempt to
manually load the Exchange snap-ins in a local Windows PowerShell session; however,
this is not supported. For information about manually connecting a remote EMS to
an Exchange server see
Windows PowerShell is also available for other products, not only Exchange. These include
Microsoft products such as System Center Operations Manager, Systems Center Virtual
Machine Manager, System Center Data Protection Manager, Microsoft SQL Server 2008, and
many features in Windows Server 2008 R2. Other third-party products also have embraced
Windows PowerShell as a management interface for their products. This momentum provides
added incentive to learn about and become proficient in using Windows PowerShell so as to
more easily manage all of these products.
Windows PowerShell and Exchange 2010
Learning to master Windows PowerShell is outside the scope of this book.
However, a basic understanding of Windows PowerShell and how it works is required to
understand portions of this book. For additional information about Windows PowerShell
scripting visit the Microsoft TechNet Script Center at
Windows PowerShell Basics
For those who have made the plunge into Windows PowerShell by using it in Exchange Server
2007, thankfully little has changed in how it functions on the surface even with all of the
changes underneath. If you have not had any experience with Windows PowerShell prior to
Exchange 2010, a basic overview will help you navigate the remainder of this book.
Windows PowerShell is an object-based operating environment built to provide a simple
yet powerful administrative interface. Each Windows PowerShell action is known as a cmdlet.
These cmdlet names always start with a verb, then have a hyphen followed by a noun. For
example, to retrieve information about a mailbox you may run the Get-Mailbox cmdlet.
Some of the common verbs used in Exchange cmdlets are:
Add This verb places an object in an already created object. For example, AddDistributionGroupMember adds a mail-enabled object into a distribution group.
Get This verb retrieves information—it will not change any settings. For example, the
Get-Mailbox cmdlet retrieves information about one or more mailboxes.
New This verb creates a new instance of an object or task. For example, New-Mailbox
creates a new mailbox.
Remove This verb deletes an object or removes it from another object. For example,
Remove-DistributionGroup removes the specified distribution group.
Set This verb makes a configuration change. For example, Set-Mailbox will change the
configuration of a specific mailbox.
The noun portion of the cmdlet (the part to the right of the hyphen) has a number of
options and is the target of the verb. For example, you can New-, Get-, Remove-, and Set- the
Mailbox noun.
This verb-noun pairing makes it easy to discover cmdlets that match the action you want
to take. If you need to create a new database, you know you need to find a cmdlet that starts
with New- and that contains MailboxDatabase. Thus to create a new mailbox database you
need to use New-MailboxDatabase.
Each cmdlet also has a variety of parameters that are used to control the actions the
cmdlet performs. For example, the Set-Mailbox cmdlet has a number of parameters,
including Identity, DisplayName, HiddenFromAddressListEnabled, IssueWarningQuota,
LitigationHoldEnabled, and so forth.
You can use more than 100 parameters with the Set-Mailbox cmdlet. For example, to
set Joel’s mailbox warning quota to 2 GB you run the Set-Mailbox -Identity Joel
Introducing Exchange Server 2010
-IssueWarningQuota 2GB cmdlet. The Identity parameter in each cmdlet is the object that
you want to perform the object against. In the previous example Identity was the alias for the
mailbox we wanted to adjust. A positional parameter means that PowerShell expects a value
for the parameter at a specific place in the cmdlet syntax.
For most cmdlets the Identity parameter is expected in the first position and does not need
to be identified. To illustrate we could modify the previous example to omit the reference to
the Identity parameter to the Set-Mailbox Joel -IssueWarningQuota 2GB cmdlet and get the
same result.
Using Get-Help
Each Exchange cmdlet also has help information available. The cmdlet that retrieves help
for other cmdlets is Get-Help. To obtain help about Get-MailboxDatabase run Get-Help
Set-MailboxDatabase, as shown in Figure 1-12.
FIGURE 1-12 Using the Get-Help cmdlet
As shown, some common parameters are available when getting information about
Exchange cmdlets: -examples, -detailed, and -full.
The -examples parameter only displays examples for using the cmdlet. The -detailed
parameter shows a more detailed version of the default help, and -full provides the full help
If your administrative workstation has Internet access you can also specify the
-online parameter to view the latest version of help online.
Using Get-Command
With hundreds of possible cmdlets, narrowing your search for the appropriate cmdlet can be
a little overwhelming. Thankfully, the Get-Command cmdlet can be used to find commands or
cmdlets. For example, if you want to search for all commands that include the word Restore,
just run the Get-Command *Restore* cmdlet.
Windows PowerShell and Exchange 2010
You can also use the Get-Command cmdlet and specify the -Verb or -Noun parameter.
To retrieve a list of all cmdlets that include Database in them you can run the Get-Command
-Noun *Database* cmdlet as shown in Figure 1-13. The Get-Command cmdlet will return
any registered cmdlet. To narrow your search to only Exchange cmdlets, you can use the
Get-ExCommand cmdlet in the same way you use the Get-Command cmdlet.
FIGURE 1-13 Using the Get-Command cmdlet
Using Cmdlet Aliases and Tab Completion
To make working within Windows PowerShell easier you can create aliases for cmdlets. One
of the default aliases is dir, which is an alias for Get-ChildItem. To view currently assigned
aliases you can run Get-Alias. To create an alias of nm for the New-Mailbox cmdlet, run the
New-Alias nm New-Mailbox cmdlet.
Another time-saving feature of Windows PowerShell is tab completion. You can start
typing a cmdlet and press the Tab key and it will finish typing the cmdlet name for you. Tab
completion is also available for cmdlet parameters.
Using Pipelines
One of the features that puts the “power” in Windows PowerShell is the ability to pipeline
information between cmdlets. In many other shells, such as those used by Linux, pipelining
is done by passing strings from one command to another. Because Windows PowerShell is
based on .NET, the information passed between cmdlets in a Windows PowerShell pipeline is
objects with attributes that can be retrieved and modified. To pass the object collection from
the output of one cmdlet into the next cmdlet, all you need to do is separate the cmdlets with
the pipeline operator, the pipe character (|).
Introducing Exchange Server 2010
A simple use of a pipeline operation is to take the output of the Get-Mailbox cmdlet
and format the output as a table. The cmdlet used to format the output as a table is the
Format-Table cmdlet, which has a commonly used alias of fl. To use this cmdlet to format the
output of the Get-Mailbox cmdlet, run Get-Mailbox | Format-Table as shown in Figure 1-14.
FIGURE 1-14 Using a pipeline to format the output of Get-Mailbox
A pipeline can consist of any number of chained cmdlets. For example, to sort the
content from the previous example based on the Name property you can run Get-Mailbox |
Sort-Object Name | Format-Table, as shown in Figure 1-15.
FIGURE 1-15 Using a pipeline to sort and format the output of Get-Mailbox
The Format-Table cmdlet can be used to show specific columns in the table if they are
specified. To display only the Name and ServerName fields in the previous example, you
would run Get-Mailbox | Sort-Object Name | Format-Table Name,ServerName. Another
command formatting cmdlet is Format-List. You can use the Format-List cmdlet, which has
an alias of fl, to format the output in a list format. Piping an object to Format-List will list each
item and all of its properties. In a table format only a few columns can be shown; however,
piping the list to Format-List will provide a detailed list that can be reviewed. Pipelining opens
up endless opportunity to perform complex administrative tasks for a command line.
Windows PowerShell is not only a command shell, but also includes a full scripting language,
including support for logic, loops, variables, functions, and error handling. Scripts can be
saved in files with a .PS1 file extension and then run from the command line. However, to
prevent malicious scripts from being accidentally run, the security policy is set to not allow
Windows PowerShell and Exchange 2010
unsigned scripts to run. In a controlled environment where you are confident that malicious
scripts are not present, you can change the security policy using the Set-ExecutionPolicy
cmdlet. The valid parameters matching the execution policies available are as follows:
AllSigned This policy requires that all scripts and configuration files are signed by
a trusted publisher.
Bypass This policy blocks nothing and the user sees no warnings or prompts when
he runs the script.
RemoteSigned This policy requires that all scripts and configuration files
downloaded from the Internet be signed by a trusted publisher.
Restricted This policy does not load configuration files or run scripts.
Undefined This policy removes the currently assigned execution policy from the
current scope as long as it has not been set through Group Policy.
Unrestricted This policy loads all configuration files and runs all scripts. If you run
an unsigned script that was downloaded from the Internet, you are prompted for
permission before it runs.
Windows PowerShell 2.0 Best Practices
Ed Wilson
Author of Windows PowerShell 2.0 Best Practices, Microsoft Scripting Guy, US East Region
hen working with Windows PowerShell, it is helpful to keep in mind what
I call the script progression. Things that are acceptable when working from
the Windows PowerShell console are certainly not good form when writing a script.
One of the features that make working with Windows PowerShell in an interactive
fashion useful is the ability to use a shortcut name, or alias. Aliases reduce the
typing burden by allowing you to type a short name instead of a very long name.
Instead of typing Get-Process, you can type gps. Instead of typing Foreach-Object,
you can type %. While making Windows PowerShell easier to use, this technique
does nothing for readability.
More than just readability, however, the use of aliases in a script can lead to
inconsistent results. This is because it is possible to delete or to change the
definition of an alias—even aliases that ship with Windows PowerShell. If someone
changes the definition of an alias to another cmdlet that uses the same signature,
no error will be generated when the alias is called, but the results of the script will
be completely different. Therefore, as a best practice use aliases on the Windows
PowerShell console, but avoid them in your scripts.
Introducing Exchange Server 2010
Another technique that is useful on the Windows PowerShell console command
line is the use of positional parameters. A positional parameter occurs when you
leave out the name of the parameter, and just include a value for the parameter. For
example, the following command starts notepad:
Start-Process notepad
If you want to stop the notepad process, you might assume you could use this
Stop-Process notepad
However, that command generates an error because of the difference between the
positional arguments. In the Start-Process cmdlet, the default parameter is –filepath,
not name as you might suspect. When you do not supply any parameters, Windows
PowerShell looks for a program named notepad in the search path, retrieves the
one it comes up with, and launches the program. The default parameter for the
Stop-Process cmdlet, however, is –id, not –name. When you do not supply any
parameters for the Stop-Process cmdlet, Windows PowerShell expects a process ID,
not a program name. When writing a script, you want to clarify what the script is
doing, in case the script becomes modified in the future to accept command-line
Speaking of command-line arguments, I consider it a best practice to incorporate
some kind of command-line help, if the script accepts parameters or arguments.
You want your users to be able to run the script directly from the command line—
you don’t want to require them to open the script and look at the contents to
figure out what the arguments are and what values are acceptable. The best way to
provide this help is to use the Windows PowerShell 2.0 help tags and integrate the
script with the Get-Help cmdlet. However, creating a parameter named help and
then performing a quick check for the presence of the parameter is sufficient to
provide help to a user.
The key to all of this is to realize that what is acceptable when using Windows
PowerShell from the command line is not the same standard to use when you begin
scripting. In the case of enterprise scripts that will be shared with others in your
organization, the standard increases proportionality, and you should be looking at
advanced functions and perhaps modules to contain your code. However, even in
a simple straight-line script you should avoid aliases and positional parameters.
For more information about using Windows PowerShell, see the Hey Scripting Guy
blog at, where I write about a wide range
of scripting topics, discussing everything from automating Microsoft Office to using
Windows PowerShell to working with Active Directory.
Windows PowerShell and Exchange 2010
Additional Resources
Messaging Application Programming Interface:
Exchange 2010 Architecture Poster (scheduled availability in August 2010): http://
Microsoft Exchange Online:
On-Premise Licensing for Exchange Server 2010:
Microsoft TechNet Script Center:
Hey Scripting Guy Blog:
Introducing Exchange Server 2010
Exchange Deployment
Exchange Deployment Project Framework
Planning Exchange Deployment Projects 43
Putting a Project Together
Case Studies Used in This Book
s an information technology (IT) professional, you might groan after reading the title
of this chapter. And you might be tempted to flip through the remaining pages of
this chapter to see whether any tables or pictures catch your interest. Before you choose
that course, consider that no matter how technically astute you are, you will undoubtedly
be able to improve how you handle deployment and migration projects. You will also
have better business relationships with non-technical people in your company if you
have a firm grasp on how to best manage an Exchange deployment project. If you have
been involved in any sort of enterprise-level messaging deployment, you can attest to
the fact that these projects are extremely complicated, they can very easily go badly, and
any improvement is welcome.
Most non-technical people and the people that manage the technical people
require that IT projects be run a lot like other projects at the company. You know—with
deadlines, project plans, and all that nonsense that most technical people couldn’t care
less about. However, being able to work with these non-technical people and make
them happy will no doubt make the project progress better and improve your overall
employment opportunities.
If you are a project manager and reading through this chapter, you may think that
an enterprise messaging project is just like any other project. Although the basic steps
are the same, there are areas that make a messaging project different than other
projects. For example, few IT projects touch so many aspects of a business. From the
users’ computers, to the network configuration, to the line of business applications, very
few areas will be unaffected. This means that messaging projects, for one, are very visible
and require political savvy, technical prowess, meticulous organization, and a drive to get
things done to be successful. Even a seasoned project manager can benefit greatly from
reviewing and more thoroughly understanding how messaging deployment projects differ
from other enterprise IT projects.
The complexity of IT operations has driven many companies, especially those with large or
forward-looking IT departments, to adopt an operational framework, such as ones based on
the Microsoft Operations Framework (MOF) or Information Technology Infrastructure Library
(ITIL). These frameworks are just that, a frame that can be used to form the way the company
plans, delivers, operates, and manages IT services. They are not full lists of rigid rules and
plans that fit every situation. Most often, consultants are hired to help adjust and implement
the framework to meet the needs of each specific business. As such, this chapter considers
using the MOF for Microsoft Exchange Server 2010 deployment projects to establish
a common set of terms and to form the basic deployment and life-cycle process.
To learn more about MOF, visit To learn more
about ITIL, visit
Exchange Deployment Project Framework
MOF has three phases: Plan, Deliver, and Operate. However, there is another operational
layer or process called Manage, as shown in Figure 2-1. Although the names of the phases
summarize simply what each phase includes, many details and processes underlie each, and
when combined they form the complete picture of MOF.
FIGURE 2-1 The MOF life cycle
The Plan Phase includes developing the overall strategy for the company. The Deliver
Phase includes developing and implementing strategic projects. The Operate Phase includes
maintaining the deployed systems. The Manage Phase is a continual process that drives
improvements to each of the operational phases.
Exchange Deployment Projects
Planning Exchange Deployment Projects
Although this isn’t an MOF training book, this chapter will apply the basic phases to an
Exchange Server 2010 deployment and provide additional detail where needed. In the next
several sections of this chapter, each of these phases is discussed as it relates to deploying
Exchange Server 2010. Use this chapter as a baseline to create your own best practices as you
discover what works best for your organization.
The Plan Phase is twofold and is usually completed with the participation of the business
owners, executives, and the technical architects, as these resources are needed to guide the
direction of any IT projects in the company. First, the Plan Phase consists of assessing the
capacity management of the current solution and then planning for future capacity and
needs. Second, this phase deals with creating a business and technology strategy around the
IT solutions leveraged by the company.
The Plan Phase can be likened to purchasing an automobile. You first recognize the need
to purchase a new car when your current car no longer meets your needs. The next step is
to determine what your budget is, which features and functionality you require, and when
you will purchase the automobile. Likewise, in the Plan Phase the decision makers identify the
need for change and then choose the high-level functionality needed as well as when the
project should be completed. The output of this phase will include the IT mission statements
and budgetary information.
A number of questions need to be answered during the Plan Phase. These questions can
be separated into business and technical questions.
Business Questions
Although the exact questions will vary for each business and over the course of time,
the following list will help start this process
What are the organization’s strategic business objectives?
The strategic objective and initiatives include projects and market trends that affect
the company today as well as those that may affect the company over the next few
years. Documenting these objectives is crucial to creating an IT vision that meets the
needs of the entire company. Have a goal to list at least three short-term and three
long-term objectives. These objectives might include market trends such as increased
pressure to improve customer service response time, or they might include being
able to achieve certification. A long-term goal might be for the company to become
publically traded or to become competitive in a new market that may require new
regulations. Having this information will shape the functionality, features, hardware,
and third-party software that should be evaluated to meet these needs.
Planning Exchange Deployment Projects
What are the budgetary goals for these types of projects?
As with any project, there is a limitation on the resources available. These resources
might be monetary, personnel-related, or even limited by time. Identify this
information before starting any project. Surprises of constrained resources later in
a project can doom the project to failure. One budgetary goal may be to reduce
overall hardware and software costs for a particular solution or perhaps to minimize
operational costs by minimizing the amount of staff required to maintain the
messaging solution.
Are there any internal business roadblocks that could cause delays or objectives to the
business requirements?
Do any internal business processes or departments need extra attention to ensure the
success of the project?
As these departments and processes are identified as risks, the risks should either be
accepted or mitigation plans should be documented and put into place.
Which tasks should be handled by current IT staff, consultants, or other outsourced
Some functions might not be strategic to the business, or might require specialized
training or skills; therefore, they might be outsourced to a consulting company or to
a service provider. Services such as Unified Messaging administration or anti-spam
services may fall into this category.
What are the business reasons for adopting the particular technology? Are there
business drivers for the migration or for the new implementation or technology?
Often there are driving factors, such as improved productivity or reduced overall cost,
that drive adoption of new technology. In this case, are there return on investment
(ROI) or total cost of ownership (TCO) metrics that must be met? Or does older
software and hardware need to be retired to avoid ongoing maintenance costs and
support issues?
What industry-specific system requirements are needed?
Many industries today have specific requirements around regulations and compliancy,
including Health Insurance Portability and Accountability Act (HIPAA), Payment Card
Industry Data Security Standard (PCI DSS), Sarbanes-Oxley Act (SOX), and others.
Because these requirements can drastically change the overall design specifications
of the environment, they need to be identified and captured in the vision of any
IT project.
Technical Questions
The following list includes some of the technical questions that should be answered during
the Plan Phase.
Exchange Deployment Projects
What are the most important technology goals and objectives for your organization?
The messaging environment is usually one of the core services of the business.
As such, the decisions made during the deployment can help or hinder the ability
to meet strategic business goals. List the main goals, which may include improved
collaboration, improved availability, improved remote user experience, legal discovery,
and Unified Messaging. These features may also include any of the other native
Exchange Server 2010 features or any third-party services that can interface with
Exchange Server 2010.
What are the service-level requirements the messaging system and related services
should meet?
Identifying the service-level requirements will affect the redundancy built into the
system, the types of service agreements needed for dependent hardware, and
organization-level agreements between departments to ensure that the system
meets these requirements. All of these can add up to complications and expense.
If the requirements and optional goals are clearly defined, you can avoid undue cost
and frustration further into the project.
What are the functional requirements for the messaging system?
Most likely the strategic requirements for the current e-mail system will not have changed
significantly for a new release. Users will no doubt need to send e-mail messages to other
users on the messaging system as well as to the Internet. While defining the functional
requirements, it is a great time to capture functionality that might be required for things
such as anti-spam, Unified Messaging, or even instances where certain users need to
be blocked from being able to print or forward specific e-mail types. The functional
requirements will be used in designing a test environment, a test plan, and eventually the
production deployment. To make sure these requirements are thorough, reach out to the
customers, the business stakeholders, and the end users. You can do this informally by
speaking with a subset of people or even by sending out surveys.
Which IT skills and resources are strategic to the organization?
When deciding which groups will be responsible for delivering and operating the
messaging service, skill sets and priorities also need to be evaluated. Perhaps specific
projects are more critical to the business and should be handled by internal staff,
whereas other projects might be outsourced.
When deploying new software and services, all involved staff will no doubt need
additional training. If new features will be utilized or new challenges addressed, staff
may need even specialized training to understand how these features are delivered,
operated, and managed in the business environment. Governmental regulations
might also require a change to operational procedures. To avoid potential problems,
complete training early to ensure that the appropriate staff knows how to meet those
Planning Exchange Deployment Projects
Also consider the track record of the IT staff in projects with a similar scope as well
as the current workload of the staff. In some cases, a project may require additional
dedicated resources with specialized skills. This is especially true with regard to
deployments because many corporate IT departments do not have staff that regularly
completes messaging deployments. Additional highly skilled resources may also
need to be considered if the project needs to be completed in a short time frame.
Otherwise, you’ll need to allocate additional time to bring the current IT staff up to
speed and able to perform the deployment tasks.
Which tools and third-party applications need to be included in the design?
As part of the strategic requirements, it is important to decide up front which strategic
tools and applications need to be integrated or included in the solution. Adding in core
applications later in the process could require design changes or cause compatibility
issues. When you work on a large project that will involve many changes, avoid any
inclination to implement many changes at once. At other times a single change will
require other changes to be completed and properly orchestrated. Before moving
forward, you need to make business decisions about how to control the amount
of change—whether that change will affect only the basic essential upgrades (servers
and clients) or will also include new applications and services.
How many users need to be included and where are they located?
Determining the number and location of users that will be affected by a messaging
project will help determine the scope of the project and the scalability needs of the
messaging system. Understanding the network configuration and available bandwidth
for each of these sites is essential to help determine the resources available as well as
what will be required at each location.
At the end of the Plan Phase, a document should be created that summarizes the general
business and technology goals and strategy for the company. This document should include
the business justification, the project scope, and the success criteria for the project. This
document might also include a project vision scope that will drive and focus the project.
This information should be signed off on by the technical and business leadership that will
ultimately be responsible for delivering the solution.
After the business and technology strategy has been defined to meet the project goals, the
delivery of the project can begin. Numerous methodologies can be used for this stage and
may vary from business to business. No matter which methodology you use, the effort you
put into this stage will allow for easier and smoother future steps.
Returning to the earlier automobile purchase analogy, the Deliver Phase is where you
identify the vehicles that meet your needs, test-drive the cars, select the final car, and then
complete the necessary paperwork to purchase the car. Likewise, the Deliver Phase is where
the products and methodology are selected and then executed to meet the criteria set out
Exchange Deployment Projects
in the Plan Phase. MOF includes five main steps in this phase: Envision, Project Planning,
Build, Stabilize, and Deploy. These are the main functions covered in the Deliver Phase in the
chapter. However, to ensure clarity of the process, these steps are broken down further into
nine discrete steps:
Step 3: Evaluate the new solution(s) and potential designs.
Step 4: Build a proof of concept.
Step 5: Create a design.
Step 6: Develop the deployment and obtain buyoff.
Step 2: Assess.
Project Planning
Step 1: Envision: Identify business and technical requirements.
Step 7: Implement a pilot. Begin pilot, adjust the plan, and complete deployment.
Step 8: Deploy.
Step 9: Post-implementation review.
The first part of the Deliver Phase is to identify the business and technical goals defined in the
Plan Phase that apply to the messaging project so as to define a project vision and the scope.
Completing this step successfully is a lot more difficult than it might seem. Doing the legwork
properly at the beginning should ensure not only that you meet current and future business
requirements, but that you also get the support you need to complete the project with the
right resources. Essentially, this vision should match up with the business’s short-, medium-,
and long-term goals as well as include optional requirements, and changes that the business
is considering or could benefit from.
Because every business is different, no single best practice answer says you should
complete this step one way or the other. Therefore, in most instances the best plan is to go
through a list of those tough questions and try to get the answers. This is not to say that all
the questions will be answered, or that all questions will be identified to fit the requirements
of your business. What is important is that conversations occur and thought goes into
gathering the requirements. During this phase, you must also describe how this vision will
impact all levels and tasks of users in the organization. This vision will be used to create
a design and an internal marketing plan.
A vision statement summarizes the project goals either as a catchy slogan or as a more
developed paragraph or list of tenets that help focus the project. Often, the vision statement is
passed down from the Plan Phase and used to drive the rest of the project including creating
Planning Exchange Deployment Projects
a full vision for the project. To create a vision for a specific project, it is sometimes helpful to
consult standard lists of items that IT organizations typically focus on improving, such as:
Service and Organizational Level Agreements (SLAs or OLAs)
Are the current agreements sufficient? Are the current agreements obtainable? Will
new hardware and software allow for improving system availability?
Operational costs
Many studies have shown that ongoing operational costs make up the majority of
a system’s cost. These costs often include staffing, power and cooling, and maintaining
the hardware and software.
Network costs
The location of the servers and clients and the amount, size, and frequency of messages
that flow into and through the system will affect the design and cost of the network.
Backup and restore cost and performance improvements
New techniques and features are available that may reduce the amount of data that
needs to be backed up. Exchange Server 2010 opens the doors for sweeping changes
to the backup philosophy and processes. These options should be evaluated.
Improved provisioning processes (for example, HR Systems)
The process of creating users and managing information and groups can be both
time-consuming and inaccurate. Some companies automate these processes by
allowing the human resources system to create and maintain user information rather
than requiring manual administrative efforts to ensure that user information is accurate.
Exchange enhancement that enables larger mailboxes
One of the major enhancements made to Exchange Server 2010 is the ability to provide
large mailboxes much more cost effectively than previous versions of Exchange Server.
Reducing licensing costs
A portion of the initial cost of every messaging solution is the software licensing.
The complexity of many of the licensing options requires that you take care to properly
estimate the number and type of licenses needed to complete the project.
Return on investment (ROI) and budgetary considerations
Most projects require extensive budgetary considerations. With additional costs or
budgetary approval a return on this additional cost is going to need to be justified.
Part of the vision of the project may be to not only roll out the new software but also
realize quantifiable benefits for doing so.
Data retention and isolation
Many companies now fall under regulations, many of which affect e-mail configuration.
These include HIPPA, SOX, the Gramm-Leach-Bliley Act, and others. If your company
is bound by these regulations, take time to understand how to comply with them. It is
best to meet with your company’s auditors to ensure that the regulations are fully
understood before a vision is created.
Exchange Deployment Projects
Auditing and compliance requirements
Again, regulations often require that access to data be tracked and logged. Certifications
such as the Payment Card Industry Data Security Standard (PCI DSS) also require that
event and access logs be archived and be accessible for set periods of time for review.
Message archiving requirements
Message retention is fast becoming a requirement in today’s business world. This puts
the IT decision makers in a position of trying to optimizing the message environment
while keeping the required amount of e-mail. Even when not required for regulatory
reasons, legal departments often request that messages be archived. Determining
the detailed functionality required for an archiving solution will help you determine
whether the native features are adequate or if additional products will be required to
meet those needs.
Antivirus and anti-spam functionality
Although anti-spam functionality is built in to Exchange Server and has improved
dramatically over the last few releases, thwarting sophisticated spammers can be very
difficult and is never foolproof. Some businesses choose to not take on this challenge
and use hosted services such as the Microsoft Exchange Hosted Anti-spam service.
When it comes to antivirus solutions, a number of available antivirus products may fit
in with the business requirements, especially if a variety of antivirus vendors are being
used elsewhere in the company or have other features that might be required.
Client access
What clients will be used to connect to the e-mail system? Will kiosks be allowed to
connect to Outlook Web App and open files? Or will any ActiveSync-capable mobile
device be able to retrieve e-mail? Will other non-ActiveSync mobile devices be
supported? As mobile devices have proliferated over the last few years it is often no
longer a question whether mobile support will be provided—the question is which
devices will be supported. As these clients are identified, what type of support will be
offered for them, if any?
Security requirements
In some instances additional security is needed to meet regulations or best practices.
This starts with a good deployment plan for appropriate network security configuration,
antivirus software, and applying software updates. This can also require segmentation
of duties by the operational staff. If this is the case, what are the specific roles that need
to be defined and implemented in the environment?
Line-of-business application integration
Are there applications integrated into the messaging system that are critical
to the business? These applications need to be tested with the new messaging
system because changes in the software may require updates, adjustments, or
other workarounds to the third-party application to be able to work with the new
deployment configuration.
Planning Exchange Deployment Projects
Performance planning
Determining the appropriate hardware and the expected application performance metrics
is required to ensure satisfactory performance for end users. Because each environment is
different, information gathered from actual usage on the current messaging environment
will yield the most accurate inputs for creating a performance plan. When migrating
between versions of Exchange or between messaging environments, usage patterns
will change. End users will behave differently depending on the features available and
limitations imposed. These behavior changes can make it difficult to estimate usage
ahead of time. During any migration it is important to understand that you plan for
estimated performance and thus latitude may be needed to account for variance.
Capacity planning and management
After the messaging system is deployed, the natural business cycle will lead to changes in
the environment. These could be fluctuations in mailbox size or number. As these usage
patterns change, so should the configuration of the messaging system. To best plan for
this, critical metrics should be gathered periodically to trend these changes and then action
should be taken to adjust for these changes. This should include a plan to scale up and down
in line with business initiatives. For example, if a business has a seasonal need for additional
capacity, the plan may include adding additional servers to handle the seasonal load.
Gathering Business Requirements
John P. Glynn
Principal Consultant, Microsoft Consulting Services, US/Central Region
ne of the top reasons for failure of a project implementation is not satisfactorily
meeting the expectations of the customer. Requirements need to be completely
discovered, examined, and agreed upon. A successful implementation project will
have agreed-upon requirements and freeze feature usage early in the planning phase.
One of the often forgotten areas of discovery is around actual business requirements.
As technologists, we tend to instantly jump to conclusions around what the business
wants or needs and look to what cool technology features we can implement. This
also underscores the importance of having a solid executive sponsor who can assist in
ensuring that the business needs are being represented in the plan. This sponsor can
also help reduce the tendency for the project scope to creep as a result of changing
requirements mid-project.
Though the IT department tends to have a pretty good foothold on what the
business requirements in the organization might entail, take the time to set up
meetings with strategic decision makers in the business groups. Understand what
Exchange Deployment Projects
their strategic initiatives involve and have conversations around how the features of
the solution can assist them in meeting their business objectives. One method for
defining the business requirements is to create a feature or service map. These maps
define how product or service features pertain to specific business groups and their
strategic initiatives.
To know where you are going you first need to know where you are. Before creating and
implementing a design it is necessary to gather and firm up documentation on what, if
anything, is currently deployed, how it is configured, and how it is used. Over the months
and years as usage patterns change and configuration changes are made, a messaging
system evolves. Design documents are often created only during deployments or when
major changes happen. Because of this it is important to verify this documentation prior
to embarking on a new messaging project. In the absence of an existing change and
configuration management history log, the system and server configuration, message
routing, anti-spam configuration, and third-party application settings should be collected. It
is likely that each of these components will be configured to meet operational needs. Some
of these applications might also have been adopted or developed either to solve a deficiency
in the messaging environment or developed in a way that interfaces in an unsupported or
deprecated way.
It is essential to identify the how, what, why, where, and when at the
beginning of the process to ensure the fidelity of the final design. Finding new integrated
applications and requirements later during the Deploy Phase will no doubt cause
unplanned delays and expense.
Care should be taken to objectively identify how well the system has been performing
and how well it is meeting the user needs. Because these issues can be emotionally charged,
information should be collected and tallied. Even if the feedback from users is negative, it
still may be important feedback that can be addressed with training or with a change in the
Identify any application that is dependent on the existing e-mail system. Because
Exchange Server 2010 touches so many other services and components of the infrastructure,
it is important to gather information about the infrastructure so that educated decisions can
be made on how to deploy Exchange and its related services:
Identify and prioritize currently deployed applications by how crucial they are to
business functionality.
Many businesses have a number of applications that integrate with their messaging
systems. These may be monitoring systems that send e-mail notifications or software
that does customer relationship management (CRM).
Planning Exchange Deployment Projects
Identify the clients that are currently in use.
Identify the clients that are being used to access e-mail. For example, which versions
of Outlook are deployed? Are there any non-Microsoft clients such as Apple Macintosh
or Linux-based client computers? Are there POP3 or IMAP4 clients (such as Outlook
Express or Outlook)? Which mobile devices are being used, and which will be supported
going forward? Is there a need to support additional clients more effectively?
Document service-level and organizational-level agreements in place.
Identify any service- and organizational-level agreements currently in place and
determine how they are being enforced.
Inventory the hardware currently in use.
Identify the hardware that is in place and determine whether any of it could be
redeployed in an updated solution. Many companies will also make sure that any
hardware is still under a maintenance agreement or that parts are on hand in case
of a failure.
Document the network infrastructure design.
Gather any available network configuration and utilization documentation. It is
important to understand the path that e-mail messages and client traffic will take
and whether bandwidth is available to handle current and predicted traffic.
Identify where the messaging servers are currently located, the number and size of
local mailboxes and public folder replicas, and the number and average size of the
e-mail messages sent and received.
Consider also gathering performance information for each of these servers, which
will help to identify any sizing concerns that might need to be addressed or identify
locations that may be consolidated.
Identify the Active Directory Domain Services (AD DS) configuration.
Exchange Server relies heavily on AD DS–specific information about the domain and
forest functional levels, as well as site and link configuration. When noting the current
configuration, also note any barriers to changing the configuration to better support
the Exchange server deployment.
Update any messaging configuration documentation to ensure that all data needed
to complete a project plan is available.
If your business has a previous version of Exchange deployed, consider using Exchange
Best Practices Analyzer to document the current configuration and to ensure that all
critical issues have been addressed.
Identify the people involved in managing Exchange and all of the dependent services.
Managing Exchange touches so many different departments and disciplines in larger
organizations, including AD DS, security services, storage, server, and networking.
If multiple people or departments control these services be sure to identify each of
them and whether they have any special requirements—such as a separate change
control process—to ensure that these issues are planned for rather than being
Exchange Deployment Projects
a surprise when deadlines are looming. Issues between departments and business units
can kill a project faster than almost any other single factor.
Perform a risk assessment.
No doubt your current deployment has issues and risks, so be sure to identify them.
Often risks include non-redundant services such as power or Internet connectivity.
They can also include insufficient training, or lack of spare hardware.
Document the executive escalation path.
Often problems during the deployment require an executive decision or guidance to
overcome hurdles or resolve resource conflicts.
After this information is identified, a vision and the objectives and scope for the project
can be generated. These business requirements can then be matched up with the current
messaging system to identify any deficiencies.
Assessing a Current Exchange Deployment
Joseph Cirillo
Senior Engineer, MCA:M Horizons Consulting, Inc.
o best prepare for a successful messaging system deployment, it is critical to
conduct a full discovery and audit of the current messaging infrastructure, its
dependencies and systems reliant on it. This simple exercise will allow you to abstract
the complexity of the current system into manageable parts to help determine the
purpose and function of the transitioned messaging system it is to perform.
The information gathered from the audit should consist of, but not be limited to,
the following items, each of which will contribute to the design of the deployed
Business requirements
Long-term vision
Service level agreement
Legal and compliance
Business continuity
Client access methods
Planning Exchange Deployment Projects
Technical requirements
Geographic information
DNS structure
Active Directory topology
Active Directory components
Current messaging topology
Current messaging components
Boundaries of the current Exchange system
Third-party applications that interface with the messaging system
Administrative model
Operations structure and tasks
Client versions
Naming standards
Monitoring and reporting
Disaster recovery
If the current messaging system is a legacy version of Exchange, I make use of the
LDIFDE.exe command-line utility to export the current Exchange configuration to a
file by executing the following command from a server class domain-joined machine:
ldifde -f ExchConfig.txt -d "CN=<Organization Name>,CN=Microsoft Exchange,
CN=Services,CN=Configuration,<Domain Naming Context>" -p SubTree
The output file (“ExchangeConfig.txt”) contains a complete snapshot of every Active
Directory object and attribute currently set by the legacy Exchange system. This
information can assist in the discovery and audit process, as well as provide insight
to items that may need to be cleaned up prior to deploying Exchange 2010.
An example of a cleanup item can be any object that references a deleted object.
For example, by performing a search for the text “0ADEL,” I found the following
Mailbox Database using an invalid Public Folder database that has been deleted:
dn: CN=MB 1-1,CN=StorageGroup1,CN=InformationStore,CN=MailServer02,CN=
Servers,CN=St. Louis,CN=Administrative Groups,CN=ExchangeOrg,CN=Microsoft
Exchange Deployment Projects
Another example of a useful piece of information to gather is the versions of
Exchange currently operating in the organization:
dn: CN=ServerName,CN=Servers,CN=St. Louis,CN=Administrative Groups,CN=
ExchangeOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,
versionNumber: 7638
A final example of a necessary piece of information to gather would be to list all the
current Exchange recipient policies and the SMTP domain(s) they currently support.
This output can be used to compose a complete list of SMTP domains currently
supported in the organization.
"dn: CN=Inbound Domains-Authoritative,CN=Recipient Policies,CN=ExchangeOrg,
CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=org"
Evaluate the Solution
With a grasp of the vision of the project and the assessment of what is currently in place, you
can begin the evaluation of products, configurations, and services to meet the project needs.
This step includes evaluating the new Exchange Server 2010 features and identifying which
ones fit your needs. This is also the time to identify third-party products and configuration
changes that might be necessary to deploy Exchange in your environment to meet the
business requirements. Evaluation includes learning about the options available. This can be
done by attending seminars, reading documentation and other material, and meeting with
Evaluate possible migration strategies. If migrating from an Exchange Server 2003 or
Exchange Server 2007 messaging environment, specific steps and requirements need to be
completed to be successful. On the other hand, if you are migrating from another messaging
product, additional work is needed to test migration options and to identify any limitations or
additional requirements and training necessary for using that migration tool or technique.
Many projects falter when not enough time is spent understanding all of the options
and tactics available for deploying, configuring, migrating, and operating the messaging
system. You should also use this time to reevaluate whether all the necessary personnel will
be available for the project or if additional resources will be needed to assist with specific
applications, hardware, facilities, or utilities.
As different portions are evaluated for inclusion in the project, it is important to cover not
only the software but also the server hardware, network configuration, storage hardware,
antivirus software or services, Unified Messaging system, mobility options, migration tools,
and archival and compliance software to make sure they can work together.
Planning Exchange Deployment Projects
To make sure these features work as expected in your environment, you might need to
create a proof-of-concept deployment. This is done in an isolated lab where testing of the
features can occur without affecting your production systems. To appropriately perform
testing, the lab environment should mimic the pertinent details of the production environment.
Proof of Concept
Traditionally, there are at least two places a proof of concept can be done. Some people
would expect to see a proof of concept after the design has been created. Others, as is shown
in this book, place the proof of concept where all the parts expected in the design are tested
together in an isolated environment. At that time all of the questions and issues are tested
to prove that they not only work in concept but also in reality. Testing should involve all
of the activities done by end users and administrators, similar to what is done during user
acceptance testing when a change is made during a change window. This allows the full range
of functionality to be tested.
Load testing should also be done at least on a small scale to gauge how much hardware will
be needed during the production rollout. If standard user and administrator tests are not already
defined, gather a list of these tests by polling the appropriate people in your organization.
Documenting a standard set of tests will ensure that the required results are gathered. If changes
are made to the standard list of tests later in the process, these tests will need to be run again.
This does not mean you should simply set up a full production environment in your lab.
You do, however, want to set up a representative sample of your production environment.
You should plan your testing so that you can use the equipment you have to maximum
advantage and proceed in a logical and controlled manner. Start by testing features that are
mission-critical to your organization.
Testing is a checkpoint against progress. Progress should always be verified by testing.
Test migration scenarios that are relevant to your environment. Although migration
documentation may seem straightforward, adjustments often need to be made to fit each
environment to give the users the best possible experience.
The phases of a proof of concept are shown in Table 2-1.
TABLE 2-1 Proof of Concept
Verifying functionality is critical in the test environment.
This testing allows time to verify assumptions, verify
functionality, and create a detailed and accurate
deployment design. This is also a good time to learn
more about the product. To prepare for this work, gather
all of the software, hardware, and configuration guides that
are being considered for use in the design.
Exchange Deployment Projects
Deploy Proof of Concept
Deploy an isolated test environment that is as close as
possible to the expected production environment and
allows testing to be completed. Testing in this phase should
include potential migration scenarios.
Perform the test scenarios and note the detailed results. Be
sure to note any changes to the test scenarios
because of new or changed features.
Review Test Results
After the testing is completed, the issues and potential
changes should be reviewed. The reasons for any
unexpected results should also be captured. For instance,
did the test fail because a feature or function didn’t work as
expected, or were there limits reached?
The review should categorize each issue’s criticality and
then each issue should be addressed by changing the
design, opening support cases with the appropriate
vendors, or adjusting the current process to accommodate
the new functionality. Any user behavioral changes should
be documented and later clearly communicated to the
affected users.
Create a Design
This is the step where you start to put all of the pieces together with the information that has
been gathered and tested to generate a design that will be used to develop the processes
and procedures around it. Although a single person may drive this process, creating a design
involves all of the disciplines involved up to this point and may require several iterations to be
created and reviewed by a group of people to have a satisfactory design.
Designing a new solution requires the creation of a detailed plan for how to configure and
install Exchange Server 2010. Describe the different types of users, what software they will
use, how they will connect, and the network configuration. Also detail the messaging and
third-party features that will be implemented and how they will be deployed. All of these
elements must align with the scope and vision of the deployment project.
The major phases of the Create a Design step are shown in Table 2-2.
TABLE 2-2 Creating a Design
Define Client
Many organizations will choose to upgrade or refresh client
configurations. A standard supported definition should include the
operating system configuration, antivirus configuration, Microsoft
Outlook version. For Outlook Web App users, the standards might
include the configuration and versions of browsers that will be
allowed. Coordinating client upgrades during the deployment phase
may require additional resources; however, it will provide end users
with an optimal experience and they’ll be able to use all of the new
Planning Exchange Deployment Projects
and Security
The Exchange Server 2010 deployment plan also needs to include
the network and security plan. The flow of e-mail messages and
connectivity to the clients requires properly designed connectivity.
Also, the security of the solution needs to be considered to protect
such a vital portion of the business communication.
Security options may include message- and transport-level encryption,
firewalls, intrusion detection and prevention, auditing, and activity
logging to apply best practices and meet regulatory requirements.
and Anti-spam
E-mail is an attack vector for many viruses, spammers, and phishing
schemes that have become very lucrative for criminals in recent years.
There is increased pressure to protect the corporate e-mail system
and the end users from these sorts of threats.
Antivirus and anti-spam designs will include the products that will be
used, where they will be deployed, and whether these services will be
outsourced or handled in-house.
Exchange Server 2010 is the foundation for messaging and
collaboration in the corporation; therefore, many businesses have
adopted or developed processes and products that integrate with
Exchange. These include line-of-business applications, unified
communications products, and workflow applications. Because
there are significant changes in how Exchange Server 2010 works,
thorough testing during the Proof of Concept phase and working with
the vendor is important to ensure that the applications work after the
In many instances changes will need to be made to optimize the
network and storage configuration for the Exchange Server 2010
deployment. Ensure that the network and storage administrators
understand the requirements of Exchange Server 2010 features so
that these groups can raise any concerns and define any changes
Changes also may be required for other portions of the network or the
current messaging infrastructure; these all need to be identified and
planned at this time.
Define and
When changes are being made—especially to important systems—
there is always some form of risk. Risk is introduced when mailboxes
are moved, when engineers complete a task for the first time, and
when restores have not been tested. One of the key areas that can
introduce the most risk is an unrealistic schedule, or one that doesn’t
build in time for risk mitigation. Attempting to complete too much
work in a single window of time often leads to rushed work and
inadequate testing and verification. This also reduces the likelihood
that a back-out plan can be executed should a failure require it to be
Exchange Deployment Projects
Communication between team members, stakeholders, and end
Communication users is essential to a well-run project. If key people do not have the
information they need to prepare and deal with the deployment
project, these individuals are likely to either fail completing their
portion of the plan or become frustrated. Some of these issues can be
mitigated by following good change-management practices; however,
additional diligence in communication should be planned for the
Communication with other groups that may be affected by changes,
such as the network or storage groups, will also ensure that issues
that arise can be handled quickly, and reduces the likelihood that
overlapping changes or initiatives could introduce risk. For example,
the network team may be planning to replace the infrastructure
firewalls and may require additional time to configure new services.
Good intra-group communication can identify this planned change
early on to ensure that testing schedules can be worked out to
minimize the risk it will introduce.
Marketing and
Training Plan
To build anticipation for the new features and functionality of the
new messaging system, it is important to market them to the end
users. This marketing should then be followed up in conjunction with
the deployment with training. This includes hands-on training for the
administrators as well as the end users.
Define Detailed
Creating a messaging architecture requires coordinating a variety of
technologies and disciplines. To succeed, all the parts must function
together when the project is complete. The architectural design needs
to include all of these components to ensure that the project is
The design should include the migration process, which defines how the
design will be implemented and how the users will be migrated to
the new design.
Often this portion is neglected and left to be figured out during
the deployment process. However, it is a best practice to define it
at this stage because it affects how the end user interfaces with the
messaging system. The migration process needs to be fully tested and
the steps fully documented.
It is important that the migration process follow the goals set forth.
In some cases the end-user impact, such as manual reconfiguration
of clients or manual migration of e-mail data is acceptable. However,
the end user may be expecting a fully automated process. These goals
will drive the process documentation and perhaps tools needed by the
migration team to be able to meet the business requirements.
Planning Exchange Deployment Projects
Develop a Deployment Plan
Developing the deployment plan takes all of the results of previous phases such as the design
and the proof of concept and creates a project plan so that the work is completed.
Creating an effective project plan takes more than technical acumen. It also requires
project management and business skills. Identify changes that need to be made to get from
the current solution to the new solution and identify stakeholders and project resources.
The major phases of this step are shown in Table 2-3.
TABLE 2-3 Develop a Deployment Plan
Create Design Milestones
Using the created design, develop project milestones
that can be broken up into discrete steps, including
the pilot. Each of these steps should also include
an estimate of the required resources needed to
complete them.
Obtain Project Resources
The messaging environment interfaces with many
points within in an organization .This requires many
people and skillsets to be involved in the project.
In small implementation projects, one person might
fill several roles; in large implementation projects,
several people might be assigned to each role. Make
sure to engage these resources early and schedule
the required time so that other projects do not
interfere with or compete with the Exchange Server
2010 deployment project.
Define Education and
Training Requirements and
Communications Plan
Users will need to be trained on any new interfaces
and actions. Adequately preparing users for any
changes is one of the most often overlooked steps;
however, it is one of the most important steps
to ensure end-user satisfaction with the project.
Communications that need to be defined include
the notifications sent to end users on milestones that
affect them. The plan also defines when and how to
keep project members and executives informed of the
project status.
Obtain Executive Buy-in
Present the solution and preliminary plan to the
executive sponsors and get feedback. Make any
necessary adjustments based on the feedback,
and ultimately get the executives to buy off on the
project and provide the needed momentum for the
project. Without their unwavering support, you are
unlikely to be successful in your project.
As previously mentioned, it is essential to get the appropriate resources engaged in the
project. Plan carefully so that you do not accidentally overlook a particular group. Table 2-4
Exchange Deployment Projects
lists some potential team members that you might consider for your Exchange deployment
TABLE 2-4 Deployment Team Members
Directory Architect
Messaging Architect
Network Architect
Security Architect
Storage Architect
Active Directory
Change Management
Business Decision
Makers or
Departmental Heads
Pilot and Pre-Pilot
Project Manager or
Program Manager
Desktop Administrator
Testing or Quality
Assurance Team
Network Administrator
User Education
Helpdesk Administrator
End Users
Technical Evangelists
A number of people who are not directly involved in the project also need to receive
updates or reports on the progress throughout the project:
Executive sponsor (if the sponsor is not your product manager)
Chief Executive Officer/Managing Director (unless your product manager or
management sponsor is performing this function)
John P. Glynn
Principal Consultant, Microsoft Consulting Services, US/Central Region
uring any project it is likely that something (people, process, or technology)
will become a roadblock in your project’s critical success path. One hopes that
these issues will be overcome through regularly scheduled project status meetings.
However, it is crucial that early on in the project—during the planning phase—an
escalation path be identified and created. Be sure to get executive sponsorship of the
path. The escalation path is the project’s lifeline when time or resource roadblocks are
encountered. Knowing when and whom to escalate to could be the difference between
an on-time, on-budget project implementation and one that drags out forever.
Planning Exchange Deployment Projects
Through properly defined risks you will have already identified several spots in your
project when escalations might be needed. Also be on the lookout for and identify
areas that have had negative implications on other projects in the past, such as
resource issues with dependency teams, purchasing processes, or the amount of
time needed to get a server physically racked and installed on the datacenter floor.
Try to bring these known issues to the first level of your escalation path very early
in the process, look for the signs that you are about to encounter them, and look
for date slips and resource contention.
When should you escalate? At the risk of raising a false alarm, you should escalate
early and often to ensure that the issue gets all the proper attention that is needed.
Without escalation the chances of project recovery are very slim. To cross some of
the silos within an organization, escalation to executives is often required. Be sure
the executives along the escalation path understand the importance of the issue
and its impact on the time and cost of the project.
Implement a Pilot
The pilot begins after you have created a workable and approved design and a project
plan that was proven in the test environment. The pilot is where the basic configuration is
completed and a subset of users is migrated to verify functionality and the migration process.
This process offers the ability to test and then adjust the project plan, and helps reduce the
risk of encountering unexpected problems during the full deployment.
The pilot also is an opportunity to get feedback from the users about how well specific
features and the deployment process are working. To be effective, this feedback needs to be
reviewed and used to resolve any issues or to document workarounds. The pilot deployment
should be used to validate that all of the planning and design work is correct and to provide
an opportunity to modify the plans so that the main rollout can go as smoothly as possible.
The pilot process can be likened to a software beta test, in which you test the deployment
and then gather feedback and bugs. As a best practice, consider implementing a second pilot
after the first pilot’s changes are incorporated. This reduces the likelihood that new problems
were introduced and provides an additional opportunity to find problems.
The number of pilot iterations that you do will depend on the complexity of the deployment
and the level of risk that will be tolerated during the deployment. Pilots should be broken into
phases so that only portions of the deployment are tested in each pilot iteration. For example,
the first pilot might only validate the Exchange Server 2010 Edge Transport’s ability to handle
a portion of e-mail traffic. Or one of the pilot phases may have to deal with users that only
access e-mail using Outlook Web App (OWA—previously known as Outlook Web Access).
This also helps reduce exposure during the pilot and focuses on which components are
being tested.
Exchange Deployment Projects
The amount of feedback and issues discovered during the pilot will help you to determine
the resources needed to handle new issues during the production rollout. It is also important
during this time to gauge the pace that you will be able to achieve during the production
rollout. When mailboxes are moved or clients are upgraded, a limited number of migrations
or upgrades can be done in a given time period, and a limited amount of resources can
handle any issues that arise during the deployment.
The major steps of the Pilot Phase are shown in Table 2-5.
TABLE 2-5 Pilot Phase
Pilot Planning
The pilot is a miniature deployment and thus needs to be
approached with the same diligence. During this planning
exercise the portions of the design that are to be tested need
to be defined and separated into discrete portions that can be
tested without interfering with the production messaging users.
This stage is also when the department and key personnel that
should be included or represented in the pilot are identified.
The key people in the information technology, human resources,
accounting, or other departments may have requirements that
need to be met and thus should be validated during the pilot.
Creating a plan for the pilot helps to ensure that each portion
is documented, which in turn helps to ensure that feedback
is gathered from each portion so that it can be repeated or
adjusted during the production deployment.
Implement the Core
Exchange 2010
Implementing the core architecture is the first step in the Pilot
deployment. This includes putting mail services in place, building
servers, and performing user acceptance testing to ensure that
the Exchange infrastructure is ready for the pilot deployment.
Pilot Deployment
When all of the appropriate change controls have been
implemented, the deployment can begin. During the
deployment it is helpful if those completing the work are diligent
about taking notes on each step they take, especially if a step
does not match the steps documented. The pilot is the last
appropriate time to tweak processes and documentation. It is
essential to have resources that are meticulous so that any issues
can be worked out.
Another overlooked step in the pilot deployment is testing the
back-out plan. Ensuring that the back-out plan works during the
pilot is much more manageable than testing and ultimately trying
to adjust the plan during the production deployment.
Finally, the plan should include what denotes a success for each
portion of the pilot. These success criteria might be a list of tasks
that need to be completed successfully, or a specific threshold of
issues or problems that cannot be exceeded.
Planning Exchange Deployment Projects
Evaluate the Pilot
The pilot team needs to diligently watch and evaluate the
pilot progress to identify any issues and fix them as they pop
up. These issues might be identified by the pilot users, the
deployment team, or a monitoring system such as Systems
Center Operations Manager. The issues should be properly
tracked in a ticketing system to ensure that they are resolved.
To elicit feedback from the users, it is important to not only
make it easy for the users to give feedback but also to ask
specific questions. This can be done in person or through simple
online surveys. If the users don’t find it easy to give feedback,
they often will not and the pilot team loses out on being able to
fix important issues before the production deployment.
Pilot Evaluation
After the pilot project is complete, the objectives and success
criteria must be reviewed. At this stage the decision is made
to make more adjustments, to continue to the Deployment
Phase, or to stop the project.
Execute Deployment
As a result of the work done in the pilot, albeit with a much larger scope, the complete
deployment plan is created. During the pilot process a lot of the details and issues were
worked out; now a very detailed plan can be created. The Pilot Phase can be likened to the
dress rehearsal and the Deployment Phase is the main performance in front of a sold-out
audience. With all of the visibility of a deployment, diligence is needed to make sure that all
of the contributors know what they need to do and when they need to do it.
The deployment plan will include a detailed rollout schedule and plan for each portion
of the deployment. This includes server deployment, user training, desktop configuration
changes, software deployment, and mailbox moves. The goal is to complete the deployment
and then smoothly transition the solution into production and into the Operate Phase.
The obvious goal is to deploy Exchange Server 2010 with as little disruption to the business
as possible.
The major portions of the Deployment Phase are shown in Table 2-6.
Ensure that during deployment the users have an advocate on the
deployment team so that user feedback and issues can be addressed or fixed. This can be
done with regular reviews of support cases opened with the help desk, surveys, or
Exchange Deployment Projects
TABLE 2-6 Deployment Phase
Create Migration Plan
and Schedule
The information gathered in the pilot should give a
good indication of the number of migrations that can be
successfully completed in a session. Create a schedule for
migrations, with additional time for contingency, back-out,
and verification in each session. Problems can arise during all
portions of the migration. It is better to schedule more time
than is needed for a migration session and be done early than
it is to have insufficient time to fully complete the migration.
Complete the migration for administrative and support
staff early in the migration deployment so that they can
gain experience and assist other users during the deployment.
Complete Deployment
and Training
Notify the stakeholders and end users about the deployment
project and of any client-side changes before you make
changes that affect the end users. If user training is required,
make sure the training occurs before any changes are made.
In cases where administrator and support staff require training
make sure it is completed early in the deployment.
Implement the
Exchange 2010
The first step in the actual deployment is implementing
any additional architecture that wasn’t deployed during
the pilot. This includes putting in place additional servers
and performing user acceptance testing to ensure that the
Exchange infrastructure is ready for the deployment.
Perform Migration
Migrating the services and mailboxes over should follow
the plan laid out. Adjustments should be made carefully
during this phase to reduce the likelihood of changes causing
additional issues. This does not mean that adjustments cannot
be made that will benefit the deployment, just that change
management procedures should be followed.
Postimplementation Review
After implementation is complete and ready to be pushed into the Operate Phase,
an implementation review should be done. This review should be completed with the input
of all the major stakeholders as well as the end users to get a complete and objective picture
of how the deployment went.
The primary goal of this review is to get executive buyoff indicating that all documented
and undocumented requirements were met for the deployment. Providing a summary of the
requirements and how each was met to the executive sponsors will help provide them with
a report card of the project.
Planning Exchange Deployment Projects
The other goals of this review are to document the changes necessary to have a stable
and complete deployment, document the lessons learned for the next deployment, and
ensure that all of the requirements have been met or addressed. A best practice is to provide
detailed documentation of any changes to the design or process. All of these aspects are
important because support of the solution will often be provided by another group when
the solution transitions into the Operate Phase. To support the solution, that group needs
accurate and complete information.
Now that the implementation has been successful, the entire messaging system needs to
be transitioned into the Operate Phase.
The end goal of the Plan and Deliver Phases is to have the services end up in the Operate
Phase. The Operate Phase is where the services are maintained at or above the level for which
the services were designed and delivered. If you were purchasing a car, this phase would be
likened to receiving the car and driving it from day to day. While you own the car you must
rotate the tires, change the oil, and perform standard maintenance. You monitor to make sure
that anytime a warning indicator alerts you to a problem you have it repaired by a professional.
Likewise in the Operate Phase, the solution is in service and performing its functions. Regular
maintenance is completed and monitoring is done to catch any issues as they arise so that they
can be fixed. The main functions in the Operate Phase are summarized in Table 2-7.
TABLE 2-7 Operate Phase Functions
The Operations team ensures that all of the Exchange services
are available. This team may also perform routine administrative
functions such as user administration, SMTP queue maintenance,
database health monitoring, and other proactive maintenance
Service Monitoring
and Control
The Service Monitoring and Control function monitors the
Exchange services to ensure system health. If problems arise or
are detected, this team—usually with automated tools—alerts
other teams to take action to rectify the problem. More than
just rudimentary service availability, the goal of this function
is to provide enough information to determine service issue
patterns. The function also provides metrics to ensure that
service-level and organizational-level agreements are being
met. Finding a balance between providing detailed timely
alerts and not overloading operations staff can be difficult.
Obviously, the quicker an issue can be resolved, the better the
customer experience will be. However, false alerts and erroneous
information can cause operations and customer service staff to
ignore this information and not act appropriately.
Exchange Deployment Projects
Customer Service
Customer service is the entry point and interface between
the customer and the entire Operate Phase. This team will
record, categorize, resolve, and close customer support requests.
The Problem Management team is responsible for identifying
the root cause and fixing ongoing and recurring problems. This
includes documenting workarounds or remediation steps for
reoccurring problems.
As the messaging deployment slides into the Operate Phase, often many of the people involved
with the deployment transition into other projects and roles as well. This requires that another
component comes into place to oversee that the solution is maintained and continues to meet
the business’s needs. This is where the MOF Manage layer comes into play. The Manage layer
is a continuous process that aims to ensure that all of the phases run smoothly and by design.
Once again this can be likened to a car purchase in that the government makes sure that the
automobile manufacturer obeys certain laws, and that the car is driven safely, operated by
licensed drivers, and maintains certain safety standards.
The Manage Phase of MOF is continuous and consists of several functions, as shown in
Table 2-8.
TABLE 2-8 Manage Phase Functions
Governance, Risk,
and Compliance
The purpose of this group is to establish well-documented
governance for all IT-related groups. This requires the group to
review and control risks. For ongoing diligence the group must
also self-audit to ensure that they are maintaining this level of
Change and
The purpose of this group is to ensure that the change and
configuration procedures are documented. This group also manages
the process of introducing change into the environment, as well as
the configuration management database. A configuration baseline
is created and periodic audits are completed to verify that the
baseline configuration is maintained. The baseline configuration
includes the operating system version, the updates applied, and
even application configuration options.
The goal of this group is to control the risks of negative change.
Due diligence can be ensured by requiring changes to be fully
and Management
Those responsible for this function keenly understand the key
principles for organizing and running IT systems. They define roles
and accountabilities and ensure that the appropriate resources are
assigned responsibilities and roles to ensure that the processes
are followed.
Planning Exchange Deployment Projects
Putting a Project Together
With all of the phases, frameworks, and checklists it can still take time and practice to refine
the process that works for your organization and for your specific project type. As you work
through a project, be sure to keep diligent notes on the progress and what does and does
not work, so that a different approach can be taken next time around. Rather than identifying
and fixing the problem, often these problems are repeated each time. By using this chapter
as a baseline for best practices and then adding your own each time you are involved with
a project, you will be able to hone the process.
Case Studies Used in This Book
This section provides a basis for the rest of the book by introducing the three main case
studies that will be used.
The first deployment example that is used in this book is Contoso, which is a basic centralized
deployment. The company has several remote retail locations and sales offices. All of the
employees access and use their e-mail, which is hosted at corporate headquarters in Seattle.
These types of deployments are usually done where the sites are adequately connected to
support the users at each site, and there is a small centralized IT department.
Contoso is currently running Exchange Server 2003 and has 750 mailboxes. The company
chose to transition to Exchange Server 2010 for the improved OWA interface for e-mail and
to replace aging hardware. Because the IT staff at Contoso does not have a great deal of
experience with migrations, they will be augmenting their team with consultants. Contoso
does not currently have any solution in place for legal discovery of e-mail messages and will
be implementing the built-in Exchange Server 2010 tools. Because most client computers
are still running Microsoft Windows XP and Office Outlook 2003, the clients will be refreshed
during the transition. Table 2-9 summarizes this information.
TABLE 2-9 Contoso Summary
Deployment Type
Single permission model
Transitioning From
Key Requirements
Seattle: One Exchange Server 2003
Microsoft Windows XP and Office Outlook 2003
Require consultants to assist in migration
Need simple legal discovery tools
Exchange Deployment Projects
Mailbox Availability SLA Target
99 percent
Active Directory Configuration
One main office, four remote offices
The company locations are configured as shown in Figure 2-2.
FIGURE 2-2 Contoso logical view
The second example deployment is Fabrikam, which has four large sites that host the
current Exchange Server 2007 computers. High availability is important to Fabrikam and the
business has chosen to transition their 7,000-user deployment into a site-resilient Exchange
Server 2010 solution.
Fabrikam has had a number of issues with unsolicited e-mail and has chosen to outsource
their anti-spam and antivirus tasks to a third party. Fabrikam has recently completed
a transition to Exchange Server 2007. With such a deep, in-house knowledge of transition, the
company has decided to now transition to Exchange Server 2010. All of the client computers
are either Windows Vista with Office Outlook 2007 or Apple Macintosh clients using an
IMAP4-based client. The Windows-based clients will not be upgraded during the transition;
however, the Apple Macintosh computers will need to be upgraded to use Exchange Web
Services or use OWA to benefit fully. Table 2-10 summarizes this information.
Case Studies Used in This Book
TABLE 2-10 Fabrikam Summary
Deployment Type
Split permission model
Transitioning From
Exchange Server 2007
Miami: Two combination Hub Transport and
Client Access Servers, one UM server and one
Single Copy Cluster Mailbox Server
Denver: Two combination Hub Transport and
Client Access servers and one Single Copy
Cluster Mailbox Server
Key Requirements
Windows Vista and Office Outlook 2007
Apple Macintosh with IMAP4-based clients
Will outsource anti-spam and antivirus
Develop a site resilient solution
Mailbox Availability SLA Target
99.9 percent
Active Directory Configuration
Two main offices, four branch offices
The company locations are configured as shown in Figure 2-3.
FIGURE 2-3 Fabrikam logical view
Exchange Deployment Projects
The third deployment example in this book is Litware Inc. This global company has numerous
and diverse sites. The company has an empty domain root to control permissions across
the domains. They have Exchange Server 2007 computers deployed in nine sites, in three
different Active Directory domains in the same forest, to handle the company’s 50,000
mailboxes. As a larger multinational company, Litware is very concerned with security so they
will be handling all aspects of their messaging system transition in-house. The company’s
IT department has deployed Edge Transport servers in both Fresno, California, and Berlin,
Germany. Litware will be using multisite failover and integrating Exchange Server 2010
into their Office Communications Service 2007 R2 deployment. Table 2-11 summarizes this
TABLE 2-11 Litware Inc. Summary
Deployment Type
Regionally distributed
Transitioning From
Exchange Server 2007
Fresno: Four Edge Transport servers, four
Hub Transport and four Client Access Servers,
one UM server, and four cluster continuous
replication environments
Berlin: Three Edge Transport servers, three Hub
Transport servers, three Client Access servers,
one Unified Messaging server, and two cluster
continuous replication environments
Tokyo: Two servers with both the Hub Transport
and Client Access roles installed and one cluster
continuous replication environments
Anaheim, Delhi, Houston, Kobe, Prague, and
Madrid: One Exchange Server with all roles
Windows XP and Office Outlook 2007
Key Requirements
Will not outsource any services
Mailbox Availability SLA Target
99.99 percent
Case Studies Used in This Book
Active Directory Configuration (root)
Three regional offices, six branch offices
The company locations are configured as shown in Figure 2-4.
FIGURE 2-4 Litware Logical View
In future chapters, you will see each of the scenarios and the final configuration of each
Exchange Server 2010 deployment in greater detail.
Additional Resources
More information about ITIL:
MOF download and related information and resources:
Exchange Deployment Projects
Exchange Environmental
Evaluating Network Topology
Evaluating and Planning for Active Directory
Planning Naming Conventions 101
Planning Namespace
Planning Certificates 111
Planning Exchange Server 2010 Placement 116
Planning Network Port Requirements
International Considerations
Mail Client Support
his chapter describes all the basic components surrounding Exchange Server
2010 that need to be considered to plan a solid Exchange implementation. These
components provide the basis to build Exchange on a solid foundation and to identify
potential issues.
It provides a basis for other chapters in this book by describing some of the
technologies that will be discussed later. For example, this chapter includes a discussion
on namespace design as well as a review of certificate requirements, which are then
taken to the next level in Chapter 4, “Client Access in Exchange 2010.” Of particular
importance when using this book is the “Planning Naming Conventions” section, which
explains the names that are used throughout the entire book.
Evaluating Network Topology
Evaluating the network topology through which Exchange Server 2010 will communicate
is crucial during the Delivery Phase, Step 2: Assess, as described in Chapter 2, “Exchange
Deployment Projects.” Often, making changes in the network infrastructure can take
a considerable amount of time because the Exchange team isn’t necessarily responsible for
making changes to the network, and communication and negotiation are often required
before network changes can be made, especially in large organizations that support
heterogeneous operating systems.
Identifying any required changes and making sure that the execution of the change can
occur without any difficulties early in the design process can save time later when you are
implementing Exchange Server 2010.
This section provides an overview of the network-related requirements for Exchange 2010.
Reviewing Current and Planned Network Topology
The first step is to collect all information about your internal network, the perimeter network,
and its external collections as thoroughly as possible from a variety of sources. These sources
include the following:
Physical network topology Verify that TCP/IP is used everywhere, which Internet
Protocol is used (IPv4 and/or IPv6), how IP addresses are allocated for servers, and that
IP subnets are used according to location.
Internal physical network connections or links This includes LAN and WAN
links, router, and so on.
External physical network connections
This includes the Internet, partner
companies, and so on.
Interconnection of physical network connections
This includes hub-and-spoke,
ring or star, and point-to-point.
Physical network speed
Network protection that might interfere
Firewall port availability to both external and internal systems.
Server name resolution used in locations or between locations (DNS/WINS
name resolution).
Defined namespaces in DNS
Divide between guaranteed bandwidth, available
bandwidth, and latency for each identified network link.
This includes firewalls that protect
physical links or network link encryption devices that reduce the link speed.
This is described in the “Planning Namespace”
section later in this chapter.
Perimeter network servers
Including any servers that are located in a perimeter
network, especially any server that provides SMTP-relay functionality.
Exchange Environmental Considerations
Be sure to identify any known changes that will occur to the network configuration during
the interim between the planning phase and the deployment phase so that the impact of the
change can be assessed just prior to deployment and the proper adjustments made.
In large organizations, gathering this information might be quite a time-consuming
effort—you may have to meet with many disparate network teams to get a thorough
understanding of the network specific details. If you want to evaluate a global network
infrastructure that includes many sites or locations, make sure you understand the
company structure, the businesses that Exchange will serve, and how these businesses are
supplied with IT currently. Having these discussions will provide you with much insight into
the current network topology and help identify any problems and potential issues that you
should consider when planning the messaging design.
Domain Name System (DNS)
This section is about the technical foundation on domain name system (DNS). It does not
include any discussion about namespace planning. The aspects of namespace planning
and disjoint namespace or single label domains are described in the “Planning Namespace”
section later in this chapter.
DNS and Active Directory
Microsoft Windows uses the DNS standard as the primary name registration and resolution
service for Active Directory. For that reason it is a basic requirement that all clients and
servers must be able to reliably resolve DNS queries for a given resource in the appropriate
DNS provides a hierarchically distributed and scalable database where hosts can
automatically update their records. These dynamic records can be fully integrated into Active
Directory when using Active Directory–integrated DNS zones.
In Exchange Server 2003 or earlier, the Windows Internet Name Service (WINS) was
required to support multi-domain environments. This is no longer required for Exchange
Server 2010.
The following list provides best practices for DNS settings when implementing Exchange
Server 2010 in your Active Directory:
Use the DNS Server service that is part of Windows Server. This provides you with
features such as Dynamic Update and Active Directory–integrated DNS zones. For
example, domain controllers register their network service types in DNS so that other
computers in the forest can access them.
Evaluating Network Topology
If you cannot use the Windows DNS Server for Active Directory and Exchange, make
sure the DNS server supports SRV resource records and allows dynamic updates of
Locator DNS resource records (SRV and A records). If your company uses BIND, make
sure you use BIND 8.x or later.
Store all DNS zones as Active Directory–integrated in Active Directory to gain the
benefit of having DNS and Active Directory replicated by a single mechanism.
This prevents the need to use different tools for troubleshooting.
Configure Dynamic Updates as Secure, thus only allowing authorized clients to register
their host name and IP address.
Only configure Forward Lookups Zones, which are required by Exchange 2010. You do
not need to configure Reverse Lookup Zones because they are not used by Windows
2008 or Exchange 2010.
More information can be found in the whitepaper “DNS Requirements for Installing Active
Directory” at
DNS Dynamic Updates
John P Glynn
Principal Consultant, Microsoft Consulting Services, US/Central Region
ctive Directory is a key dependency for Exchange; without it Exchange does
not and will not properly function. Active Directory is based on the DNS
service. Without DNS, many components of Active Directory, Exchange, and client
interaction fail to function properly. When a domain controller is installed on
a domain, a series of records is created. These DNS records contain service location
records for Kerberos, LDAP, GC, site-specific information, and a domain record that
is a unique GUID.
Exchange servers utilize these DNS records to locate authentication or other
specific services. Exchange will use Active Directory site-specific service location
records for services such as: locating the closest Global Catalog servers to utilize for
name resolution, locating domain controllers to utilize for Exchange configuration
information, and routing messages between remote Exchange servers. Exchange
servers as well as workstations that run the Exchange management tools rely
heavily on Kerberos for authentication. Therefore, it is equally important that the
Exchange server A records are registered within DNS correctly as well.
Exchange Environmental Considerations
As a best practice, implement DNS with dynamic updates enabled. I have been in
a few environments where transient Exchange and client issues were tracked to
missing or invalid SRV records. Some of the specific issues that I have seen include
the following:
Invalid host record for the Exchange Server—the connection suffix of the
server did not match the DNS record causing Kerberos authentication failure.
The domain GUID records for the domain were incorrectly entered under the
_msdcs zone, causing improper identification of domain controllers for the
Active Directory domain.
Slowness issues resulting from missing site location records, causing
Exchange to possibly grab a Global Catalog located at a distant site—thus
communication needs to flow across WAN links. This might be because some
or all of the following records are missing or incorrect in DNS: _ldap._tcp
Most modern DNS implementations in use today support dynamic updates.
As a best practice it is advisable to allow only secure updates, which prevents
rogue systems from injecting invalid entries into your DNS zones.
A few environments refused to globally enable dynamic updates on their zones.
We were able to convince the team to allow only domain controllers to dynamically
update their records. Exchange server records were created manually. However,
A records are familiar to DNS administrators and less likely to be incorrect. As with
any manual process, it can be incorrectly created, so always double-check. If this is
not possible, try to convince the DNS team to temporarily enable dynamic updates
during the DCPROMO process and the subsequent reboot to allow the domain
controllers to dynamically create/update all of the necessary records. Obviously this
requires more process overhead, but in the long run it will save on issues, outages,
and hours of troubleshooting caused by incorrectly configured DNS records.
Several tools are available to validate records and the functionality of DNS, such as
DNSLint, DCDiag, and netdiag. Other standard tools include nslookup, ipconfig,
and nltest.
DNS Records Used by Exchange 2010
DNS provides a number of critical functions for Exchange 2010. This section provides
an overview of the most important records in DNS.
Evaluating Network Topology
A records or Host records provide a host name to IP address mapping. Host records are
required for each domain controller and other hosts that need to be accessible to Exchange
Servers or client computers. Host records use IPv4 (A records).
Here is an example of an A record: IN A
All Exchange 2010 servers use DNS to locate a valid domain controller or global catalog.
By default, each time a domain controller starts the Netlogon service, it updates DNS with
service (SRV) records that describe it as a domain controller and global catalog server,
if applicable.
SRV resource records are DNS records. These records identify servers that provide specific
services on the network. For example, an SRV resource record can contain information to
help clients locate a domain controller in a specific domain or site. For that reason, the SRV
records for domain controllers and global catalog servers are registered with several different
variations to allow Exchange servers locating a suitable domain controller or global catalog
during the Active Directory discovery process.
One option is to register DNS records by site name, which enables computers running
Exchange Server to find domain controllers and global catalog servers in the local Active
Directory site. Exchange Server always favors the selection of a domain controller and/or
global catalog from the same site that Exchange is installed into.
Here is an example of an SRV record: IN SRV 0 100 389
A Mail Exchanger (MX) record is a resource record that allows servers to locate other servers
to deliver Internet e-mail using the Simple Mail Transfer Protocol (SMTP). An MX record
identifies the SMTP server that will accept inbound messages for a specific DNS domain. Each
MX record contains a host name and a preference value. When you deploy multiple SMTP
servers that are accessible from the Internet, you can assign equal preference values to each
MX record to enable round-robin between the SMTP servers. You also can specify a lower
preference value for one of the MX records. All messages are routed through the SMTP server
that has the lower-preference-value MX record, unless that server is not available.
Here is an example of an MX record: MX 10
Exchange Environmental Considerations
You don’t need MX records for Hub Transport servers that are involved in internal
mail routing. That is only required for external SMTP routing—for example, to the Internet.
More information about MX records and how they are used for SMTP message routing can
be found in Chapter 5, “Routing and Transport.”
Exchange Server 2010 uses Sender Policy Framework (SPF) records to support Sender ID spam
filtering. If you want to use this feature, you need to configure the SPF records in DNS. This
is described in more detail in Chapter 7, “Edge Transport and Messaging Security.”
Split DNS
Split DNS or split-brain DNS is about setting up separate DNS zones so that DNS requests
that come from the Internet will resolve to different IP addresses than requests coming from
your internal workstations or servers. In other words, as shown in Figure 3-1, if the Internet
client resolves, it will receive an IP address that is associated with an external
firewall solution that is sitting in the perimeter network. The internal client will get an IP
address associated with the internal Client Access server array.
FIGURE 3-1 How split DNS works
The benefit of using split DNS is that it helps control client access. Internal clients use
the internal systems instead of the external systems. In other words, internal users’ sessions
aren’t handled by the firewall application and you do not expose internal IP addresses or host
names to the Internet.
You can also limit access to specific hosts that are part of the perimeter network or force
users to take a specific communication route. For this reason it is a best practice to implement
split DNS in every Exchange organization that has server roles exposed to the Internet.
Evaluating Network Topology
Fixed IP Address vs. Dynamic IP Address
It’s important to know whether your company has an Internet provider that provides your
company with fixed IP addresses or if you’re using dynamic IP addresses to access the
Internet. If your servers that have some relationship to external communication, such as
Edge Transport servers, have fixed IP addresses and your DNS entries (MX or A records) are
registered accordingly, you’re working with the best practices approach.
However, a fixed IP address might be a cost issue, especially in small companies. Thus some
companies might want to implement Exchange 2010 based on an Internet provider that only
provides a dynamic IP address. If you’re in this situation, you should consider a Dynamic DNS
service that lets you register your dynamic IP address to their DNS service. However, make
sure the dynamic DNS service includes the following:
Your IP addresses should automatically register in DNS when the IP address changes.
Your router and/or Dynamic DNS service provider need to support this.
IP updates should be replicated in DNS real time to make sure the change is known to
the Internet immediately.
For external SMTP servers to know how to send messages to your domain, the DNS
record for your domain should include an MX record.
The Dynamic DNS service should provide you with an SMTP relay host to send
messages to the Internet. If you directly send messages, your server is quite likely to be
detected as spam because of your changing IP addresses. Many SMTP servers consider
dynamic IP addresses as not trustworthy and thus don’t accept messages from them.
If you consider these points, you’ll have no problem operating Exchange Server 2010 when
using a dynamic IP address.
Internet Protocol (IPv4 and IPv6)
Internet Protocol Version 4 (IPv4) is commonly available and the basis for communication
between any device on the Internet. The successor of IPv4 is called Internet Protocol Version 6
(IPv6), as defined in RFC 2460 in 1996.
IPv6 was developed to correct many of the shortcomings of IPv4, such as the limited pool
of available IP addresses and the lack of extensibility. Because IPv6 addresses are 128 bits
long (compared to IPv4 addresses, which are 32 bits long), there are enough IPv6 addresses
available for every living insect, animal, and person on earth.
Unfortunately, IPv6 is not an extension of IPv4 but a completely new protocol. Therefore,
an IPv4 network can’t communicate directly with an IPv6 network and vice versa. Any
network device, such as a router, needs to be able to understand IPv6; otherwise, IPv6 causes
communication problems.
Exchange Environmental Considerations
IPv6 for Windows
The client and server software needs to support IPv6 to use it. The following Microsoft server
operating systems support IPv6:
Windows Server 2003 (IPv4 is installed and enabled; IPv6 is not installed by default.)
Windows Server 2008 (IPv4 and IPv6 are installed and enabled by default.)
Windows Server 2008 R2 (IPv4 and IPv6 are installed and enabled by default.)
Microsoft also recommends that you do not turn off IPv6 in a clustered
environment because Windows Server 2008 R2 Clustering uses IPv6 for internal
Not only does the server need to support IPv6, but also the client operating system.
The following Microsoft client operating systems support IPv6:
Windows XP Service Pack 1(SP1) or later (IPv4 is installed and enabled; IPv6 is not
installed by default.)
Windows Vista (IPv4 and IPv6 are installed and enabled by default.)
Windows 7 (IPv4 and IPv6 are installed and enabled by default.)
For more information about IPv6, see the IPv6 for Microsoft Windows FAQ
Hardware Provider Recommended to Disable IPv6
for Windows Server 2008
or a recent project I consulted my server hardware provider, who recommended
turning off IPv6 because their network interface card (NIC) drivers caused
problems especially when using NIC Teaming. The operating system was Windows
Server 2008; thus we used the following registry key to disable IPv6 from all LAN
interfaces, connections, and tunnel interfaces:
DisabledComponents set to 0xFFFFFFFF (DWORD type)
After a reboot, even IPCONFIG.exe no longer showed IPv6 addresses. You can find
more information on how to disable IPv6 at
Evaluating Network Topology
Windows Failover Clustering on Windows Server 2008 R2 requires IPv6 and the
Exchange 2010 Database Availability Group uses some elements of Windows
Failover Clustering. However, Exchange 2010 does not use IPv6 within a DAG. This
does not mean that you can disable IPv6. Even though the DAG neither depends on
nor uses IPv6, disabling IPv6 completely for Windows Server 2008 R2 is not a tested
scenario and could therefore result in unpredictable consequences for a DAG.
IPv6 for Exchange Server 2010
Because Exchange Server 2010 runs on Windows Server 2008 or R2, you might think that it
automatically supports IPv6. However, you should consider a few things before planning for
IPv6 and Exchange 2010. The following Exchange Server roles can cause issues when using
IPv6 addresses:
Hub or Edge Transport Features such as IP Allow List Providers or Sender
reputation do not support IPv6 because they require static IP addresses.
Unified Messaging All features do not support IPv6 but need IPv4 to work
Client Access Server Autodiscover and EWS Web services endpoints because you
cannot configure an IIS binding for an IPv6 address—WCF throws a Watson exception
if you try to configure it.
Database Availability Group (DAG) Even though you cannot define an IPv6 DAG
IP address, IPv6 is supported. When static IPv4 addresses are specified for a DAG,
it only uses IPv4. When no static IPv4 address is specified, Exchange use DHCP for the
IPv4 addresses and also creates IPv6 address resources.
Exchange Server uses the Windows network stack to process any request. Each request
depends upon two things:
Name resolution (when initiating the request)
Packet type (when receiving a request)
First, the name resolution will determine how to initiate the request to another computer
based on which address (IPv4 or IPv6) is resolved first. When the name resolution comes back
with an IPv6 address, this address is used to initiate the request.
Second, packet types do not mix IP versions midstream. If the request comes in as IPv4,
the response will also use IPv4, and the same is true for IPv6. As for unfulfilled requests,
they should be handled before name resolution is completed and would otherwise fail after
name resolution in the same way other transient network failures occur. For features that
don’t support IPv6, Exchange causes the request to fail so that the client initiates another
request using IPv4. Thus an IPv6 request, even to the Unified Messaging role, does not cause
a problem but is just ignored.
Exchange Environmental Considerations
The official Microsoft support statement for IPv6 is that Exchange Server 2010
running on Windows Server 2008 or R2 requires an IPv4 address. Exchange Server 2010 is
not supported in a pure IPv6 environment where you disable the IPv4 protocol.
Understanding Client Load Patterns
Another important aspect that should be understood when planning for Exchange 2010 is the
current client load patterns—namely the traffic between Outlook clients (or other mail clients)
and the Exchange server.
The scope of this task depends on what your current mail clients are. If most of your clients
use POP3 or IMAP4 clients, the load on an Exchange server is significantly lower and you can
plan for many more users on a single server.
If you’re using a MAPI-based client, such as Microsoft Outlook 2003 or Outlook 2007, you
need to analyze which profile your average users fall into to understand the impact of the
traffic to the Exchange server. You can use the information available from your monitoring
system, such as Microsoft System Center Operations Manager if available. Alternatively you
can use Windows Performance Monitor to collect the performance information of your
clients. Consider using the following performance counters:
Messages sent/received per day
Average message size
Messages read per day
Messages deleted per day
Outlook Web Access logon and logoff per day
Consider collecting the client data from each Exchange server or mail server (when coming
from a non–Exchange System) for at least a couple of days (at peak times, not on weekends)
to have a representative aggregation of performance data.
Identifying Current Client Load
Andy Schan
Senior Consultant, Schan Consulting Inc., Canada
o work out the current client load, my last couple of projects had Quest
MessageStats in place, so I sat down with the MessageStats data and Microsoft
Excel and crunched the numbers for the last couple of quarters to come up with
a profile of their typical users.
Evaluating Network Topology
To come up with a useful client load picture for scaling the new environment,
I typically make assumptions similar to the following:
10-hour workdays
5-day workweeks, Monday–Friday
Messages/day/user derived from the data are all sent during normal working
I also use the messaging data for the previous calendar year quarter and derive
message/day data from that, to ensure that I’m seeing a reasonably accurate picture
of the average client activity in the environment and to minimize any effects from
brief periods of increased activity. I may also go back two quarters, if the previous
quarter includes quiet periods such as summer vacation or Christmas holidays.
I focused on figuring out messaging activity (number of messages/day sent
and received, calendaring activity, and so on) rather than actual bits over the
wire, which changes once you get them to cached mode and a newer version of
Outlook. Together with the data from the client, I used the following Microsoft
whitepaper to assess the load: “Outlook Anywhere Scalability with Outlook 2007,
Outlook 2003, and Exchange 2007” at
After you collect the results, you can compare the data with Table 3-1 to identify how to
classify your client profile according to Microsoft’s most common client profiles.
TABLE 3-1 Common Client Profiles
Sent per day
Received per day
Average message size
Messages read per day
Messages deleted per day
Outlook Web Access logon and
logoff per day
When you have identified your typical client load pattern, you should plan to implement
a load-generating tool such as Exchange Load Generator 2010 to verify your Exchange
server hardware performance. Exchange Load Generator 2010 (64 bit) is available
Exchange Environmental Considerations
You’ll find more details on how to plan your Exchange hardware and how to use the
Exchange Load Generator in Chapter 13, “Hardware Planning for Exchange Server 2010.”
Perimeter Network
Communication to the Internet or external network is also important. You’ll find information
about the required firewall ports or protocols that need to be configured later in this chapter
in the “Planning Network Port Requirements” section. This discussion does not cover other
security options, such as IPsec or VPN, that allow clients on the Internet to directly connect
to their internal network.
The recommended deployment for Exchange Server 2010 Internet access includes two
firewalls or routers in a back-to-back firewall scenario, which enables you to implement a
perimeter network between the two. An external firewall faces the Internet and protects
the perimeter network. You then deploy an internal firewall between the perimeter and your
internal corporate network.
In the perimeter network you place any Internet-facing server, such as the Edge Transport
role of Exchange Server 2010. Microsoft does not support any topologies that put firewalls
between a Client Access, Hub Transport, Unified Messaging, and a Mailbox (MBX) server.
Putting these roles between a firewall could cause issues because they use dynamic ports
that could be blocked unintentionally by the firewall. The only Exchange 2010 role supported
for deployment in a perimeter network—and with a firewall server separating it from other
Exchange servers it talks to—is the Edge Transport role.
The Edge Transport server role should never be a member of your internal
domain, but should be a stand-alone server or member of an available perimeter Active
Directory forest.
The most common servers that are placed in the perimeter to support Internet access are:
A smart host to route SMTP messages between the internal and external network,
such as Edge Transport server role or any other smart host.
A reverse proxy or application-layer firewall that supports client-related traffic such
as Autodiscover, Outlook Web App (OWA, previously known as Outlook Web Access),
Outlook Anywhere, ActiveSync, POP3, IMAP4, SMTP, and so on to the internal network.
Microsoft Forefront TMG and Microsoft ISA Server 2006 are example application-layer
firewalls. However, don’t underestimate the scalability challenges for software-based
reverse proxy servers. Any implementation that needs to handle more than 100,000
concurrent connections on an ongoing basis should focus on a hardware solution.
Evaluating Network Topology
You should not deploy the Client Access Server role in a perimeter network to reduce
the attack surface of your internal forest. Because the Exchange computer account of the
Client Access Server role has elevated privileges, it can be used by an attacker to destroy your
Active Directory. Instead, use an application-layer firewall such as Microsoft Forefront Threat
Management Gateway (TMG) to publish the Client Access server services to the Internet.
If you do not use an application-layer firewall from Microsoft, consider the following key
areas for choosing a firewall application of highest security standard:
Pre-authenticate traffic To prevent unauthenticated traffic from entering the
corporate network.
Packet inspection Application-layer firewalls allow for identification of known
protocol attacks prior to entering the corporate network.
Intrusion Detection System (IDS) Simplifies identification of attacks on the
system. If attacks occur internally, chances are they will be successful and difficult to
detect because they may look like typical traffic, whereas if the proxy starts requesting
RPC to other servers, or tries to get through the firewall, it is blocked and logged.
Fixed Ports/IP Addresses Only specific ports and IP addresses are allowed into
the corporate environment.
Group Membership allowance Provides the capability to allow only specific
groups to access specific applications; for instance, my current customer does not
allow hourly workers to access mail externally.
Load balancing Arrays of reverse proxy servers can distribute network traffic for
a single URL.
As a best practice, always implement a reverse proxy or application-layer firewall if
you want to provide Internet access to your Exchange servers. However, some companies,
especially in the small to medium sector, do not implement any kind of security between their
servers and the Internet. If you do not implement an application-layer firewall, consider the
following recommendations:
Deploy a firewall between the internal and external network and open only the ports
or protocols you need.
Implement a server certificate for all your Exchange servers. (This can be a single
certificate that includes the required domain names, as described in the “Planning
Certificates” section of this chapter.)
Require SSL to encrypt client communication (for Outlook client traffic).
Require TLS for SMTP and SSL if you enable POP3 or IMAP4.
Make sure that any operation requires authentication.
Implement Forms-based authentication for Outlook Web App.
This provides you with at least minimum security but still might expose some of your user
data to the Internet. However, it’s better than nothing.
Exchange Environmental Considerations
Avoiding Pitfalls by Providing Technical Recommendations
The following list provides ways to avoid potential pitfalls on the network topology side.
Any problems must be rectified before Exchange Server 2010 can be installed at the location.
Make sure that the physical network speed of sites that will host Exchange Server 2010
has at least 64 Kb per second of bandwidth available.
Exchange Server 2010 does not support a pure TCP/IP v6 (IPv6) environment. If you’ve
already implemented pure IPv6 addresses anywhere in your company, make sure that
they also support IPv4 addresses; otherwise, the clients might encounter errors in
communicating with Exchange Server 2010.
IP subnets should map to the locations of the company and should be non-overlapping
between locations. However, sometimes single locations have multiple IP subnets,
which is fine. If IP subnets are spanned between multiple physical locations, make sure
the WAN link between them matches LAN link speed—10 megabits per second (Mbps)
or more.
Make sure your Active Directory sites match IP subnets for each location.
DNS must be used for network name resolution.
Active Directory uses service (SRV) resource records in DNS to register a list of domain
controllers for client use. If you do not use Windows Server 2008 DNS Service for Active
Directory, make sure that your DNS server software supports the resource records!
To receive messages from the Internet, an appropriate mail exchanger (MX) resource
record in DNS is required for the company’s domain name.
Additional Beneficial Server Settings
Joe Cirillo
Senior Engineer and Architect, Horizons Consulting, US/Central Region
icrosoft has always provided some invaluable guidance regarding the
installation and automation of Exchange. Over the years, I have found some
additional settings I like to confirm or set to help ease administration or to further
ensure that the installation will occur without error.
Network Interface Card Naming Standard
I always try to reduce ambiguity for any objects that I interface with. Because
I often refer to the settings on the NIC when troubleshooting, I like to provide
an easy-to-follow naming standard for the NICs. This is particularly helpful when
multiple NICs are configured, as required when using the Exchange Server 2010
Database Availability Group.
Evaluating Network Topology
Confirm that the adapter binding order is correct
Because the server host name in the registry will bind to the first interface in the
adapter/bindings list, the binding order must be set properly.
I have seen connectivity issues caused by improperly configured bindings. Anytime
you make changes to the network configuration (such as adding protocols,
adapters, modems, or services), the binding order can potentially change. Be sure
to check the binding order on server install and anytime you make changes to the
network configuration.
Confirm that Windows Remote Registry Service is running
Exchange Server requires access to the local registry to retrieve various settings.
One example is the Exchange Setup program. The Exchange Setup program uses
DNS to obtain the fully qualified domain name (FQDN) of the local computer to
access the registry. If the Windows Remote Registry Service is not running, setup
will be unable to access the registry, causing the installation of Exchange to fail.
Confirm that Date, Time, and Time Zone are set properly
Exchange gets its date and time information from the operating system. Windows
Directory servers need to have their time synchronized for Kerberos authentication
to work correctly. Kerberos works by exchanging time-stamped authenticator
identification tokens. By default, directory servers have a maximum tolerance for
computer clock synchronization of five minutes. This is known as clock skew. Clock
skew is the range of time allowed for a server to accept Kerberos tickets from
a client. If the clock skew is greater than five minutes, Kerberos authentication fails,
which results in cascading authentication failures for Exchange Server.
If an Exchange server’s time is out of sync with the Domain Controller time, issues
will occur such as Exchange services failing to start or client connections being
rejected. To prevent issues caused by time skew, make certain of the following:
The Exchange server has network connectivity with the Domain Controller.
The Exchange server time is synchronized with either the Domain Controller
time or the time server that is used by the Domain Controller.
Desktop Background
Setting the Desktop Background to display useful information is also useful for
eliminating ambiguity when logging onto a server. It is very inefficient to have to
click through several diagnostic windows just to find that you logged on to the
wrong server, or to find information such as the IP address or operating system
version. If you manage multiple computers you will benefit greatly by displaying
relevant information about the Windows server on the desktop’s background.
You can find the BgInfo tool at
Exchange Environmental Considerations
Import any Trusted Root Authorities onto the local computer
Depending on how you are managing certificates (such as by using a stand-alone
Certificate Authority, enterprise Certificate Authority, or third-party Certificate
Authority), you may need to add the certificate for a foreign Certificate Authority
to the Trusted Root Certification Authorities container on the local computer. If this
is necessary, be sure to add the certificate for the foreign Certificate Authority
to every server you install to ensure consistency in your build and to avoid
communication errors between servers.
Any e-mail client connecting to the Exchange Server’s secure sites must trust the
Exchange Server’s site certificates. Before it can successfully negotiate a secure
SSL/TLS link with the Exchange Server, the e-mail client must trust the Certificate
Authority (CA) issuing the Web site certificate to the Exchange Server’s services.
If the certificates issued by the foreign CA will be used by client-facing Exchange
services (such as Outlook Web App or Outlook Anywhere), be sure to also add the
certificate of the foreign CA to the Trusted Root Certification Authorities container
on any user workstation or mobile device.
Evaluating and Planning for Active Directory
Active Directory is the integrated, distributed directory service included with Windows Server
operating systems. Many applications, such as Exchange Server 2010, integrate with Active
Directory. This creates a link between user accounts and applications, which enables single
sign-on for applications. Additionally, the Active Directory replication capabilities enable
distributed applications to replicate application-configuration data.
How Exchange 2010 Uses Active Directory
The Active Directory database is divided into logical partitions—namely the schema partition,
the configuration partition, and a domain partition for every domain.
Windows Server 2008 and R2 includes a tool called Repadmin that can be used to list all
Active Directory partitions available. Figure 3-2 shows the result from the Litware Scenario
using the command Repadmin /showrepl.
As shown in the figure, Active Directory is made out of the configuration, schema,
application, and domain partitions.
Evaluating and Planning for Active Directory
Schema Partition
Domain Partition
Domain Partition
FIGURE 3-2 Using Repadmin to look at Active Directory partitions
Additional information about Active Directory Partitions can be found in
“Active Directory Logical Structure and Data Storage” at
The Schema Partition
Before Exchange Server 2010 can store information in Active Directory, the schema
partition needs to be modified so that Exchange-related objects (such as connector
or mailbox information) and attributes (such as an Exchange Mailbox server or a user
object) are defined in the Active Directory schema. The schema partition stores the
general layout of all Active Directory objects and its attributes. It includes two types
of information:
Schema classes The objects that can be created
Schema attributes The properties that can be used for each object
Exchange Environmental Considerations
Each and every domain controller and global catalog server in Active Directory
contains a complete replica of the schema partition. Thus it is important to plan the
Exchange Server 2010 schema extension accordingly—you cannot remove a schema
How to Safely Extend the Schema
Ross Smith IV
Senior Program Manager, Exchange Server Product Group, Microsoft Corporation
chema extensions are permanent. Care should be taken to ensure that a schema
extension is successful because a failed schema extension may mean rebuilding
the forest. The preferred way to mitigate the impact of a failed schema extension
is to isolate the schema master by disabling its ability to replicate changes to other
domain controllers in the forest.
This is accomplished by executing the command repadmin /options +DISABLE_
OUTBOUND_REPL. When outbound replication has been halted on the schema
master, you can then proceed with extending the schema. If the schema extension
is successful, you can re-enable outbound replication and allow the changes to
propagate throughout the forest. If, on the other hand, the schema extension fails,
you simply shut down the schema master server, wipe it, and seize the schema
master role on another domain controller.
Because Exchange depends on Active Directory, each released Exchange version
implemented different schema versions. To identify the current Exchange schema version,
the schema attribute ms-Exchange-Schema-Version-Pt was added. In the attribute, you can
identify the schema version by looking at the rangeUpper attribute and identify the Exchange
version according to Table 3-2.
TABLE 3-2 Exchange Schema Version Numbers
Exchange Server 2010 or Exchange Server 2007 SP2
Exchange Server 2007 SP1
Exchange Server 2007
Evaluating and Planning for Active Directory
Exchange Server 2003
Exchange Server 2000 SP3
Exchange Server 2000
In Figure 3-3 you can see that the Exchange Schema version is currently Exchange
Server 2010 or Exchange Server 2007 Service Pack 2.
FIGURE 3-3 Checking the Exchange schema version in ADSI Edit
Using the rangeUpper attribute you can also identify whether a schema update was
replicated successfully to the local domain controller. By connecting to the DC and then
verifying that the attribute has the current value, you can be sure that the schema update has
It is true that the Exchange Server 2010 schema extension also includes
the Exchange 2003 and 2007 schema extensions. However, if you plan to ever install an
Exchange 2003 or 2007 server into the organization after Exchange 2010 is deployed,
you must install the older Exchange Server version as the first server and install Exchange
Server 2010 afterwards. Exchange Server 2007 should include the Mailbox, Client Access
Server, and Hub Transport roles. Once you have installed Exchange Server 2010, you will
not be able to install Exchange 2003 or 2007 anymore!
Exchange Environmental Considerations
The Configuration Partition
The configuration partition contains configuration information for the Active Directory
forest. Additionally, some distributed applications and other services store information in the
configuration partition. This information in the configuration partition replicates through the
entire forest so that each domain controller and global catalog has a replica of it.
The configuration partition stores each type of configuration information in separate
containers. A container is an Active Directory object similar to an organizational unit (OU) that
you use to organize other objects.
Exchange Server 2010 stores information such as global settings, address lists, connections,
and so on to the configuration partition. Figure 3-4 shows you how to look at the information
Exchange Server 2010 stores in the configuration partition. You can see it either using ADSI
Edit or Active Directory Sites and Services. (You’ll need to enable the Show Services Node.)
You also need to be a member of the Organizational Management group or the View-Only
Management group; thus, you must have Exchange Organizational permissions to expand
below the Exchange Organization level.
FIGURE 3-4 Exchange configuration in the configuration container
Evaluating and Planning for Active Directory
The Domain Partition
The domain partition holds domain-related information in containers as well as OUs.
It includes information about users, groups, and computers in that domain. The domain
partition is stored on every domain controller of that specific domain. Every global catalog
server has a subset of information from every domain partition in the forest, as well as
a complete copy of its own domain’s objects. For example, a global catalog server in
a different domain will contain information on the individual user, such as the user’s display
name or its SMTP addresses, but not its password.
For every Exchange-prepared domain (meaning that the Exchange Setup /PrepareDomain
has been run for the domain) Exchange Server 2010 creates an OU called Microsoft Exchange
System Objects in which it will store Exchange-related system objects such as the mailbox
database’s mailbox and public folder proxy objects.
You can verify that a domain was Exchange Domain–Prepared by looking at the
ObjectVersion attribute on the Microsoft Exchange System Objects OU in that domain.
For Exchange 2010 RTM it should read 12639, as shown in Figure 3-5.
FIGURE 3-5 Identifying an Exchange-prepared domain
The Application Partition
Application partitions hold specific application data that the application requires. The main
benefit of application partitions is replication flexibility. You can specify the domain
controllers that hold a replica of an application partition, and these domain controllers can
include a subset of domain controllers throughout the forest.
Exchange Environmental Considerations
Currently the only application that uses the application partition is DNS, to store DNS
zones in the partition as Active Directory–integrated DNS zone. Exchange Server 2010 does
not use application partitions to store information.
Table 3-3 describes the application partitions commonly available in Active Directory.
TABLE 3-3 Application Partitions in Active Directory
Replicates to all DNS servers in forest
Replicates to all DNS servers in domain (is created once
you add the second DNS server to the domain)
Of course only DNS servers that run on Domain Controller can access the application
partitions; thus all DNS zones that are stored in this partition are Active Directory–integrated.
Using ADSI Edit you do not see application partitions by default as well-known
naming contexts. To look at them you need to directly address them using their
distinguished names (DNs). You can identify the DN using a tool such as
repadmin /showrepl.
Active Directory Replication Impact on Exchange 2010
Active Directory replication is a crucial component of Exchange 2010. As described in
previous sections, the different partitions store Exchange-related configuration data.
This data is automatically replicated between Active Directory sites using Active Directory
replication mechanisms.
Because Exchange 2010 relies on the replication mechanisms to work correctly, you might
face delays in configuration caused by replication latency. For example, if you configure
an Exchange Server in the domain, but your current computer is located
in, you will see that configuration is not immediately available in the domain You need to wait until Active Directory replication takes place and
replicates the changes to the domain. Normally the replication between sites happens every
15 minutes or longer depending on your Active Directory Site Link configuration.
There are two possibilities to overcome the replication delay:
Configure your EMC or EMS so that you directly use a domain controller located in the
target domain. For example, in EMS you can set the preferred domain controller using
the following cmdlet:
Set-ADServerSettings –PreferredServer <DC FQDN>
Evaluating and Planning for Active Directory
Use Repadmin to push replication to target domain. For more information on
the Repadmin tool, read the Microsoft whitepaper “Monitoring and Troubleshooting
Active Directory Replication Using Repadmin” available at
Besides Active Directory replication, Active Directory sites and IP site link information
are important for message routing between Exchange servers. Exchange 2010 uses the cost
assignment that is part of every IP site link to determine the lowest-cost route for traffic
to follow when multiple paths exist to the destination. This information is used by the Hub
Transport role to decide to which Exchange Hub Transport server a message is sent to when
the target Exchange Hub Transport server is not available.
More information about Active Directory sites, IP site links, and their relevance to message
routing in Exchange 2010 can be found in Chapter 5, “Routing and Transport.”
Active Directory Requirements
For Exchange Server 2010 Active Directory and domains must meet several requirements.
Consider the following when evaluating your current Active Directory design:
The server on which the Schema Master role runs must have at least Windows Server
2003 SP1 (32-bit or 64-bit) installed.
You need to run Windows Server 2003 SP1 or later (32-bit or 64-bit) on global catalog
servers in every Active Directory site where you plan to install Exchange Server 2010.
If you still have older global catalog in your environment, it is recommended that you
upgrade all your domain controllers to prevent any problems.
Active Directory must be at least in Windows Server 2003 forest functionality mode.
Windows Server 2008 functionality mode is supported if your Exchange organization
includes Exchange 2007 and/or 2010.
All domains that will include Exchange Server 2010 servers or recipients must be
at least in Windows Server 2003 domain functional level.
Because of the importance of the global catalog in an Exchange Server organization,
you must deploy at least one global catalog in each Active Directory site that contains
an Exchange 2010 server.
Single versus Multi-Forest Implementation
The following forest implementations are available:
Single Forest
Exchange Environmental Considerations
Resource Forest
Hybrid Forest
Figure 3-6 shows the different forest approaches and in what forest user accounts
mailboxes and Exchange servers are available.
Single Forest
Forest 1
Hybrid Forest
Resource Forest
User Forest
Resource Forest
Forest 2
Forest 1
Forest 2
FIGURE 3-6 Exchange Forest Topologies
One issue that you should keep in mind before deciding your forest design is the
management effort required to administer the various types of forest. Sometimes you
might make a decision regarding the kind of deployment to execute only to realize in
production that it’s harder to manage—and perhaps even that some tools don’t work in
a specific configuration. The old KISS rule (keep it stupid and simple) comes to mind here,
which you should always consider if you have the chance.
Single Forest
An Active Directory forest is a set of one or more domain trees that share common
configuration and schema information. A forest is a security boundary. By default, no account
from outside the forest can hold security principals to access information inside the forest.
A single Active Directory forest design provides the following characteristics:
A single forest that matches the Exchange organization. (This is the most common
and easiest approach.)
No limitations to Exchange and Outlook functionality.
Evaluating and Planning for Active Directory
The multi-forest (or cross-forest) implementation consists of at least two loosely connected
forests that operate independently from each other but are somewhat connected. This forest
approach includes the following characteristics:
Includes multiple Exchange organizations, often multiple SMTP addresses.
Users are part of the different forests.
Can include multiple service providers that administer their own forest and do not
have access on another forest.
Common when one company buys another company without integrating it into the
existing Active Directory forest.
The forests have to share a trust relationship before data can move between the
forests. This is the requirement so the forests can be connected from the Exchange
perspective using, for example, linked mailboxes. This approach has quite a few
limitations. For example, a user cannot easily open a mailbox from another user that is
located in a different forest.
Synchronization of availability information and public folder information between
forests is often very complicated.
Resource Forest
The resource forest implementation consists of one or more account forests and an Exchange
forest that includes all Exchange servers, mailboxes, and distribution lists. The account forest
contains the user accounts and security groups. This forest approach includes the following
Mailboxes are attached to disabled user accounts and associated to user accounts in
the account forest.
Administration between the account forest of the organization and the Exchange
forest is separate. Most often you will create a resource forest in a hosting
environment. A service provider provides the resource forest that is connected using
a one-way trust to the account forest. This ensures that the service provider has no
permissions in any way in the account forest and only can manage the resource forest.
You can have better Exchange capabilities and availability with a clean resource forest
that is fully controlled by the Exchange administrators.
The concept of messaging in a cloud—such as Microsoft BPOS or the implementation
of Exchange on a hosting platform—can be seen as a resource forest implementation.
Typically reduces token bloat by moving the DL membership of a user object to
a different forest.
Because all the mailboxes are part of the same resource forest, there are no limitations
to Exchange and Outlook functionality. (If this is not the situation, the implementation
is called a hybrid forest.)
Exchange Environmental Considerations
Hybrid Forest
The hybrid forest combines the concepts of a resource forest and a single forest—thus,
a hybrid forest contains not only user accounts or resource mailboxes (such as user-disabled,
mailbox-enabled objects) but also includes active mailboxes (mailbox-enabled user accounts
where Exchange server is in the same forest). This forest approach includes the following
Each forest may contain a combination of enabled and disabled user accounts that
are either mail enabled or mailbox enabled.
Differs from a resource forest in that all forests have mailboxes, and you might find
mail-enabled users and disabled mailbox-enabled users in the same forest.
Contains both resource mailboxes (user-disabled mailbox-enabled objects) and active
mailboxes (user-enabled mailbox-enabled objects).
Common in a migration to or from a resource forest model or in an organization that
has a resource forest for some business units but also uses the resource forest as the
primary forest for other business units.
Only the users of the same Exchange organization have no limitations to the Exchange
or Outlook functionality.
Planning a Forest Design
Andrew Ehrensing
Principal Consultant, Microsoft Consulting Services, US Central Region
icrosoft recommends starting all designs with a single forest/single domain
environment for Active Directory. On some occasions business requirements
dictate a change from this model to a multi-forest model; however, this should be
avoided whenever possible. Introducing multiple forests adds significant complexity
and cost in both capital and operational expenses.
Single vs. Multi-Domain Implementation
After the forest design has been made, the discussion about domains follows. This discussion
is only necessary if you have a multi-domain environment and your Exchange implementation
will be part of a single forest design.
In such an environment, you need to decide whether you want to install all Exchange
servers in a single, Exchange-dedicated domain or place Exchange in the domain where the
user accounts are stored. Especially in a single forest implementation you need to consider
the following domain approaches.
Evaluating and Planning for Active Directory
Single Domain
A single domain is where Exchange servers and users are located in the same domain.
This approach has the following characteristics:
Simplest implementation and thus the easiest to manage
Centralized administration
Used if only one domain is available
Always start with a Single Domain as the basic design; only move to a different
domain design if forced!
Single Exchange-Dedicated Domain
A single Exchange-dedicated domain can be found in a multi-domain forest where one
domain is created just for hosting Exchange servers and managing distribution lists.
This approach has the following characteristics:
Exchange servers are maintained in their own dedicated domain. The disadvantage is
that the extra domain brings the extra costs that stem from deploying and managing
an additional domain.
Exchange administration of dedicated domain can be totally independent from Active
Directory administration of forest. This means that the administrators can perform
all administrative tasks on the Exchange servers without requiring any administrative
rights in other Active Directory domains.
Has a special requirement for additional user domain controllers that need to be
available where the Exchange servers are located.
Common if you have your own internal service provider for Exchange.
A multi-domain approach includes the Exchange servers directly in their user domains—
thus, the Exchange servers are spread between the different domains. This approach has the
following characteristics:
Used if the Exchange administrations is split between different divisions or
departments that own their own domains
Used if you have a geographic domain design and thus want to add the Exchange
servers to their respective regional domains
In a multi-domain environment you have to make sure that you configure the right scope
in EMC and EMS. The following cmdlet configures a forest-wide scope:
Set-ADServerSettings -ViewEntireForest:$true
Exchange Environmental Considerations
If you can choose between a single- or multi-domain implementation for
Exchange, it is a best practice to use a single domain. This reduces complexity dramatically
and will be much easier to manage.
A Mix of Single and Multi-Domain Implementations
multinational electronics company with more than 70 Active Directory
domains in the forest mixes a multi-domain and single Exchange-dedicated
domain approach. The reason for running two different approaches was that parts
of the company have a centralized Exchange administration, but some countries
manage the Exchange servers on their own. However, issues in Exchange caused by
replication latency and other problems supported the decision to move to a single
Exchange-dedicated domain approach.
Planning Naming Conventions
Another area that needs to be considered is planning for naming conventions for your
objects. In a large, complex organization (such as the scenario of Litware) it is easy to fail
to understand what function a server performs at first glance; a good naming convention
conveys the function of a server to an administrator without forcing the administrator to
examine the server’s properties.
Many organizations implement naming conventions for key components because of
this requirement. Naming conventions can allow administrators and users to easily identify
the purpose of an object without requiring input from others. Typically, the larger the
organization, the more strict these naming conventions can become.
Naming conventions help you to easily identify key elements of an object. For example,
a server’s role, location, and purpose can be identified in environments that have grown
beyond a tangible number.
Of course, some small companies out there have just a handful of servers, but what if
you have hundreds of servers that you can no longer easily remember? In this situation, you
should start thinking of naming conventions for your environment.
The most common naming convention is for the Display Name attribute of users and
distribution groups. It might get complicated to identify a user when there is no strict
convention, especially in companies that have mailboxes from all over the world. We’ve
seen organizations in which some administrators created the mailboxes with the convention
Firstname Lastname and others using Lastname Firstname. Of course this causes confusion
and should be corrected.
Planning Naming Conventions
Not only do you need to consider the Display Name—in Exchange 2010 it is
recommended that you also define the following names:
Database Availability Group (DAG)
Active Directory Site
Distribution Groups
Naming conventions vary according to the organization’s requirements and depend on
locations, geographic distribution, and other factors. There is no single best convention
To provide some guidance on naming conventions, the following examples were
developed for this book. You can use them as basis to define your own conventions.
Remember that you might need more objects to be defined than are described in this section;
in general it is good to describe all names that are required, but not every name available.
Server Name
The server name can be used to identify the physical location of a server in terms of country,
site, city, or datacenter. It is very common for the server name to also include service-specific
information. This eases the process of identifying the role of the server by just looking at
its name.
Because some city names are long, it is recommended to use an abbreviation such as
an internal site code or the three-letter airport code. In this book, the server name includes
the city (only cities with short names are used), the role that is running on it, and a number:
<cityname>-<2 letter service spec><2 digit number>
Table 3-4 describes the details about the service-specific abbreviations used to create the
server name in this book.
TABLE 3-4 Server Name Service-Specific Abbreviations
Multi Exchange Role Server
Mailbox Server/Public Folder
Hub Transport
Edge Transport
Exchange Environmental Considerations
Client Access Server
Unified Messaging
Domain Controller
Multi Role Server
Examples for server names include:
Dallas-EX01 (multi-role Exchange located in Dallas)
Munich-DC01 (DC located in Munich)
Miami-CA01 (Client Access server located in Miami)
Berlin-ET01 (Edge Transport located in Berlin)
Database Availability Group Name
Database availability group names can include information on physical sites included in the
replication (such as Berlin and Fresno or the Active Directory site names) but for most of
the implementations a simple numbering is probably sufficient. In this book, the database
availability group name includes DAG name and an increasing number. The convention is
as follows:
DAG<2 digit number>
DAG01 and DAG02 are both examples of database availability group names.
Database Name
In Exchange versions before 2010 Mailbox, databases always were fixed to a server name.
Thus it was common practice to include the Exchange server name or server information in
the database name. This practice changed in Exchange 2010—a database is no longer fixed to
a server. The database is no longer associated with the server, thus the database name should
include other aspects such as the DAG to which the database is associated, the main location
where the database is used, or the purpose of the database (such as mailbox limits).
In this book, the database name includes the DAG it is part of, the city where it is based,
and an increasing number. You can argue that we did not consider site resiliency, because
having the city name as part of the database name might confuse people in the event
of a cross-site database failover. However, in that scenario you can clearly identify which
databases are failover databases just by looking at the name. The convention is as follows:
<DAG>-<city>-<2 digit number>
Planning Naming Conventions
Examples of database names include:
Active Directory Site Name
The Active Directory site name should follow the purpose of the creation for multiple Active
Directory sites—namely, to define different locations, subsidiaries, or branch offices. In most
cases these are the physical boundaries of a location or a datacenter, and indicate a different
connectivity between them. Thus the important factor in the name for identification is
the location or datacenter name. In some cases for larger companies you might consider
including the site code or street name into the site name to identify it correctly.
In this book, the Active Directory Site Name includes the word Site, a dash, and then the
city or region the site spans. The dash needs to be included because spaces are not allowed
in the site name. The convention is as follows:
Examples for Active Directory site names include:
User Names
To find the users of your system it is important to define a convention for making the user
names. This can follow simple rules such as last name and first name separated by a comma
or space and can include other information, such as initials when needed or departmental
information after the name (such as when you have two identical names). Because many
names are not unique, the general rule is to add as much information as necessary to identify
the user.
In this book, the user names follow the simplest user name rule: last name followed by the
first name separated by a comma. The convention is as follows:
<Lastname>, <Firstname>
Examples of user names include:
Healy, Joe
Richardson, Shawn
Exchange Environmental Considerations
Planning Namespace
Before you set up your Exchange organization, one of the most important areas that needs
to be planned is your internal (organization-facing) and external (Internet-facing) namespace.
A namespace is a logical structure commonly represented by one or more domain names
in DNS.
Namespace planning is most important for the Client Access Server role. However, many
considerations are also needed for the Hub Transport and Edge Transport roles. This section
should provide the general basis for understanding the importance for namespace planning.
The topics are also discussed in Chapter 4, “Client Access in Exchange 2010”; Chapter 5,
“Routing and Transport”; and Chapter 7, “Edge Transport and Messaging Security.”
During migration or transitions you also might need to consider special namespace
requirements. These are addressed in Chapter 14, “Transitioning from Exchange Server 2003
and Exchange Server 2007.”
The official Microsoft support statement for Exchange 2010 and SLD/Disjoint/
Non-contiguous Namespaces can be found at
Namespace Scenarios
When you implement your Exchange 2010 organization, you need to decide how your
internal and external namespace will be defined. This is important because it affects the
following areas:
DNS configuration of your Exchange servers
How your certificates are created and what names they include
Client Access (Outlook Anywhere, Outlook Web App, POP3 and IMAP4, SMTP)
If you have multiple datacenters available where your Exchange 2010 servers are located,
consider the following general advice for namespace planning:
Plan your namespaces such that both datacenters can be active.
You provide failover capabilities or can manually switch over a datacenter.
Each datacenter needs the following namespaces, depending on your client
connectivity capabilities:
This still allows for incremental deployment.
Outlook Web App/OA/EWS/EAS namespace
POP3/IMAP4 namespace
RPC Client Access namespace
SMTP namespace
Consider which datacenter will maintain the Autodiscover namespace.
Planning Namespace
To start planning your namespace, you need to consider the various locations of clients
and servers and the physical connections they have to the Exchange servers. Typically the
namespaces align with your DNS configuration.
You can choose from the following namespace-planning options:
Consolidated data center
Single namespace with proxy sites
Single namespace with multiple sites
Regional namespaces
Multiple forests
Consolidated Data Center
This namespace scenario is the simplest one and includes a single namespace to access
a single physical site where all the Exchange servers are hosted. The Contoso scenario
described in Chapter 2 of this book is an example of a consolidated data center. This scenario
has the following advantages:
Only one or very few DNS records need to be managed.
Only one or very few certificates are required for your Exchange organization.
All users use the same URL to access the Exchange server.
This namespace scenario is configured by providing Internet access to the Client Access
server by opening the relevant ports by a firewall or implementing an application layer
firewall such as Forefront Threat Management Gateway in the perimeter network.
If you want to provide POP3/IMAP4, you need also to consider how the clients will send
their messages using SMTP. To overcome this easily, you can configure the Hub Transport role
on each Client Access server. Otherwise, you need to plan separately for message sending
and message receiving namespaces.
Single Namespace with Proxy Sites
This model is based on the consolidated datacenter model but proxies the requests to
the physical Mailbox server located at another site. One of the sites has one or more
Internet-facing Client Access servers that proxy the requests.
This scenario has the following advantages:
Only one or very few DNS records need to be managed.
Only one or very few certificates are required for your Exchange organization
All users use the same URL to access Exchange server.
The disadvantage of this model is that most users will access their mailboxes using
proxying, thus accessing their data might be slower across latent WAN links.
To configure this namespace model, you need to configure the ExternalURL option of the
Client Access server(s) at one site, and make sure that the ExternalURL settings on all the other
Exchange Environmental Considerations
sites are configured to $Null. This configuration ensures that the Client Access server does
not redirect the connection to the target Client Access server, but instead proxies it. Redirect
means that the Client Access server forwards the connection to the target Client Access
server; proxy means that the Client Access server contacts the target Client Access server and
retrieves the data for the connection.
Single Namespace with Multiple Sites
This model uses a single namespace for an organization that has multiple sites. For example,
the Litware scenario would be a possible candidate for this approach because the company
has multiple physical sites and wants to use a single namespace. The two possible approaches
to implementing a single namespace with multiple sites are with a Client Access server proxy
site or an intelligent firewall:
The Client Access server proxy site approach includes Client Access servers based in
a separate Active Directory site that is used to proxy the traffic to the site where the
user’s mailbox is located. To configure this namespace model, you need to configure
the ExternalURL option to the single namespace of the Client Access servers at all sites.
The intelligent firewall approach uses an application-layer firewall such as Forefront
TMG and decides during client authentication that the traffic is forwarded to the
correct target site based on configured rules. To configure this namespace model, you
need to configure the ExternalURL option to the single namespace of the Client Access
servers at all sites.
This scenario has the following advantages:
Only one or very few DNS records need to be managed.
Only one or very few certificates are required for your Exchange organization.
All users use the same URL to access Exchange server.
The disadvantage of this model is that you must either have an application-layer firewall
that is capable of forwarding the traffic to the correct physical sites like Microsoft Forefront
TMG or a Client Access server proxy site.
Regional Namespaces
This model uses one namespace for each region or site. The users will use their regional
namespace to access their messages.
This scenario has the following advantages:
The client traffic is automatically optimized based on the region or site level.
(For example, if you implement a namespace based on a city, all users of that city
will use the local access.)
Performance and end-user experience are optimized.
Failover is provided if the regional namespace is unavailable by using a different
namespace (if the Mailbox server of the site is still available).
Planning Namespace
The disadvantage of this model is that you need to manage multiple DNS records as well
as multiple certificates. Additionally you have multiple Internet entry points that require
a firewall.
The regional namespaces model is recommended if your topology includes
multiple sites that have their own Internet connectivity.
Multiple Forests
The multiple forest model uses one dedicated namespace for each forest. For example if
Contoso and Litware merged, Contoso users would need to access and
Litware users would use to access their mailboxes. Client Access server proxy
redirection between the two forests does not work, so if one forest is not available, no users
would be able to access their messages.
In this model, every namespace that is implemented needs its own Internet access point,
DNS record, and a certificate. Within each forest, use a regional namespace model to improve
customer experience.
Disjoint Namespace
The disjoint namespace model is a special scenario for planning the namespace. You face
this scenario when your primary DNS suffix on domain controllers or member servers in the
domain is not the same as the DNS domain name of your Active Directory domain.
For example, you have a disjoint namespace when the Exchange Server that is part of the domain has a primary DNS suffix of This computer (as the primary
DNS suffix that does not match the DNS domain name) is said to be disjoint.
You might require these namespaces to be different for several reasons. For example,
if DNS management in your company is split between administrators who manage Active
Directory and administrators who manage networks, you may need to have a topology with
a disjoint namespace.
Microsoft Exchange 2010 has three supported scenarios for deploying Exchange in
a domain that has a disjoint namespace:
Scenario 1 The primary DNS suffix of the domain controller is not the same as the
DNS domain name. Computers that are members of the domain can be either disjoint
or not disjoint.
Scenario 2 The Exchange servers in an Active Directory domain are disjoint, even
though the domain controller is not disjoint.
Scenario 3 The NetBIOS domain name of the domain controller is not the same as
the subdomain of the DNS domain name of that domain controller.
Exchange Environmental Considerations
In Exchange 2010 you may need to configure the DNS suffix search list to include multiple
DNS suffixes if you have a disjoint namespace.
In a disjoint namespace environment, you must configure the following:
All disjoint domains need to be added to the msds-allowedDNSSuffixes attribute of
your root domain.
The DNS suffix search list must include all DNS suffixes, including the disjoint DNS
As mentioned, it is required to configure every disjoint domain in the msdsallowedDNSSuffixes attribute of your root domain. For example, if you have the disjoint
namespace that you need to add to the forest, configure the
settings on the domain level using the Windows Server 2008 Administrative Tool ADSI Edit,
as shown in Figure 3-7.
FIGURE 3-7 Configuring a disjoint namespace in the domain
Additionally, make sure that the DNS suffix search list contains all DNS namespaces that
are deployed within your organization. To do this, you must configure the DNS search list for
each computer in the domain that is disjoint. The list of namespaces should include not only
the primary DNS suffix of the disjoint member computer and the DNS domain name, but also
any additional namespaces for other servers the Exchange Servers may interoperate
(such as the monitoring server).
For more information on Exchange 2010 and disjoint namespaces, see “Understanding
Disjoint Namespace Scenarios” at
Planning Namespace
A Disjoint Namespace Example
Carsten Allendoerfer
Head of System Services Group, Johannes Gutenberg-University Mainz, Germany
ur disjoint namespace consists of the Active Directory domain called (we have a single domain/single forest implementation) but all
servers use the primary DNS suffix of Only domain controllers use
the correct suffix of the Active Directory domain.
We started to run Exchange 2010 in early beta phase and had quite a few problems
caused by the disjoint namespace scenario. We still have one unsolved problem with
the Active Directory Topology Discovery Service, which causes problems when the
NetLogon service starts too early and no network connection is available. You can
resolve this by using fixed IP addresses for the servers instead of DHCP. I assume
this is a general problem in Windows Server 2008 R2 and not an Exchange 2010
Sometimes applications from Microsoft and other companies take for granted
that the DNS suffixes are equal to the Active Directory Domain name. Take my
advice: carefully test every application before implementing it. From what I’ve
learned in the past 10 years running in a disjoint namespace scenario, I would never
recommend it to anyone.
Single Label Domains
A single label domain (SLD) is basically a DNS domain name set equal to a NetBIOS domain
name. It does not contain a suffix such as .com or .org and consists only of a single word,
Before Active Directory, in Windows NT a single label domain was the basis so some
companies continued to use an SLD in Active Directory. In Windows Server 2008 R2 you can
no longer create SLDs—if you find an environment that still has SLDs, consider migrating to
a normal namespace to prevent issues in the future.
Exchange Server 2010 supports SLDs; however, the Exchange product team does
not recommend this configuration because future versions of Exchange or third-party
applications might cause issues in this scenario. For that reason, you should move your
organization to a normal namespace scenario.
Exchange Environmental Considerations
Non-contiguous Namespaces
A non-contiguous namespace (sometimes referred as a discontiguous namespace) is
a namespace where an Active Directory forest includes multiple domain trees of different
names. Thus the forest is not defined hierarchically. A forest can have one or more domain
trees, and these trees are defined by the DNS names. For example, would be
a domain tree in the forest.
In Windows Server 2008 R2, you can configure multiple domain trees by using the
Advanced Mode Installation in the Active Directory Domain Services Wizard (dcpromo.exe).
If you have similar tree names (such as and, be sure
to choose different NetBIOS domain names for their respective domains. If you select the
same NetBIOS names for both trees, the configuration is not supported. The general rule
is that each domain must still register a unique legacy NetBIOS domain name.
If your organization has a non-contiguous namespace scenario, DNS must be configured
so that every Exchange server is able to resolve all domain names in the environment.
You are also required to configure msDS-AllowedDNSSuffixes within the Active Directory
environment for all namespaces used in the forest. For more information on how to configure
msDS-AllowedDNSSuffixes refer to the section “Disjoint Namespace” earlier in the chapter.
Planning Certificates
This section is about certificates that are generally used by Exchange 2010 to secure
communication between the servers and between the client and the servers. It explains the
basics about the certificates, and then dives into the details of what types of certificates
are available and what you need to know to plan the names you put into your certificates
About Digital Certificates
A digital certificate basically is an electronic representation of users, computers, or other
devices or services. A digital certificate consists of a private and a public key pair.
The private key is stored only on a computer, device, or possibly a digital ID card. In many
companies these keys are kept under the same security level as the user password for
Windows. The public key is used to encrypt data for you and is required by everybody that
wants to security communicate with you.
A digital certificate is always issued by a CA with a private and public key pair. The process
is similar to applying for a passport at your local governmental office. The governmental
Planning Certificates
office issues your passport, like the CA, and the passport you receive is like the digital
You use digital certificates in relation to sending and receiving e-mail in two areas:
Data encryption Make sure the data you transmit cannot be decoded somewhere
between the sender and the receiver.
Digital Signature The receiver can verify that the data received was originated by you.
Types of Certificates
There are three types of certificates based on the authority that issues the certificate:
self-signed certificates, Windows public key infrastructure (PKI)–generated certificates, and
third-party certificates. Table 3-5 provides an overview of these types of certificates and
their uses.
TABLE 3-5 Types of Digital Certificates
Self-signed certificates
When Exchange 2010 is installed, a new certificate
is generated automatically if no computer
certificate is available. This certificate is used
by default to encrypt all communication inside
and outside the Exchange organization. If you
access your OWA using a Web browser, you
need to confirm that the server’s certificate is
correct because you do not trust this certificate
by default. Self-signed means that the computer
itself acted as a CA and signed its own certificate.
Windows PKI–generated certificates
These certificates are issued by a Windows
CA (such as Windows Server 2008 R2’s Active
Directory Certificate Service) and you can
request them at no extra cost and install them
immediately. Normally, they are not trusted
publicly, so you need to make sure that the root
certificate is imported at every server, client,
and device that does not belong to your Active
Directory. In your Active Directory forest, the
information is distributed automatically.
Third-party certificates
This type of certificate is automatically trusted
within the Internet and can be purchased by
a third-party CA such as VeriSign. It is the easiest
and least time-consuming way to implement
certificates, but you need to buy them. Thus, you
probably won’t have an official certificate for
every Exchange server in your environment.
Exchange Environmental Considerations
You cannot use self-signed certificates for mutual TLS or Domain Security communication
to and from the Internet in Exchange 2010—only Windows PKI–generated certificates or
third-party certificates are supported there.
If you decided to use Windows PKI–generated certificates for Internet
messaging, you have to make sure that your partners’ servers trust your root CA
(by importing your root certificate).
Working with Certificates in Exchange 2010
Exchange uses certificates to communicate securely between the different server roles.
By default each Exchange server uses either the certificate issued by the domain or issues
its own self-signed certificate and uses this one for communication. If you do not require
secure communication to the Internet, a self-signed certificate works without issue.
However, if you want to consider a secure Exchange 2010 implementation, some server roles
require an independent certificate if they are communicating with the client. Table 3-6 provides
an overview of which Exchange Server roles require which certificate for which purpose.
TABLE 3-6 Server Roles and Certificates Requirement
Hub Transport
Windows PKI or third-party
for external, self-signed for
internal mail flow
Client Access Server
Outlook Web App (OWA)
Windows PKI or third-party
Exchange Web Services
Outlook Anywhere
Edge Transport
Windows PKI or third-party
Mailbox Server
Any certificate
Unified Messaging
SIP over TLS
Windows PKI or self-signed
Planning Certificates
Application Layer
Windows PKI or third-party
Outlook Web App (OWA)
Exchange Web Services (EWS)
Outlook Anywhere
An application-layer firewall such as Microsoft TMG can be used to proxy traffic between the perimeter and
internal network. For that reason it can proxy all Exchange protocols but does not require it.
Exchange 2010 certificates need to have a certain format to work correctly with the TLS
protocol. Because the Edge Transport servers might have multiple domain names or service
connection points (SCPs), you have two options:
Use a single certificate on your server(s) with Subject Alternative Names (SAN) support,
also known as Unified Communications Certificates.
Use individual certificates.
Microsoft recommends using a SAN certification because it’s simpler to administer
on the servers. Unfortunately, it is also more expensive than a normal certificate if
purchased from a third-party CA.
Thus when considering certificates in Exchange 2010, you need to answer two key
Where do you want to place certificates? Do you want to use one certificate per
server or a single certificate for all your servers? If you want to use a single certificate
for all your servers, make sure you distinguish between internal and external servers.
If you use an application-layer firewall in a perimeter network, consider implementing
a separate certificate for it.
What SAN names should the certificates have? If you use one certificate for all servers,
you need to consider all SAN names that you want to add.
To plan for all the domains or host names that should be included in the certificate,
Table 3-7 should provide you with a basic understanding of what is required.
Exchange Environmental Considerations
TABLE 3-7 Creating Certificates for Exchange Roles
Hub or Edge
Client Access
Domain name(s) used
for TLS
Client Access server’s FQDN
(for internal client proxy for
ECP, OCS 2007 R2)
Hub Transport server’s
Service FQDN for OWA,
ActiveSync, POP3, IMAP,
and so on
UM server’s FQDN
(for SIP over TLS)
Short names or NetBIOS names are no longer required in a certificate in
Exchange 2010. However, if your users are using short names in the browser to access
OWA, or if you implement the certificate on legacy Exchange Servers, you should also add
the short names to the certificates.
Consider carefully the following best practices regarding creating certificates for
Exchange 2010 :
Use SAN certificates that can cover multiple host names.
Minimize the number of certificates. If your company’s security policy permits,
use only one certificate for all Client Access, Hub/Edge servers, and the
application-layer firewall.
Because Office Communication Server (OCS) 2007 requires the server name in the
certificate principal name (PN) and a key of <=1024 bit keys, it is recommended that
you use an additional certificate if OCS is required.
Put only the names you need in the certificate.
Don’t list computer host names on certificate host name lists, if at all possible.
If using a certificate for each datacenter, ensure that the Certificate Principal Name is
the same on all certificates. Otherwise, Outlook Anywhere will not connect in a site
failover scenario.
Planning Certificates
Planning Exchange Server 2010 Placement
This section explains the planning aspects you need to consider to plan Exchange 2010 server
placement at your company’s locations. It starts with considering the domain controllers
because they play an important role when Exchange Server 2010 is installed and then
discusses what Exchange roles should be planned at which site.
Domain Controller and Global Catalog Placement
In planning your Exchange 2010 server placement, never forget to include domain controller
or global catalog servers. Because Exchange 2010 requires good communications with
Active Directory to access its configuration, the logical starting point is to consider domain
controllers and global catalog servers that already exist and verify whether additional
servers are needed. This is especially important because Exchange 2010 won’t start without
communicating to a global catalog server. For that reason it is important that you consider
the following areas in your planning:
At least one global catalog (which obviously is also a domain controller) must be
available in the same Active Directory site where you plan to install Exchange 2010.
For redundancy reasons, it’s always good to have at least two global catalog servers
available in an Active Directory site where Exchange 2010 will be installed.
Using 64-bit domain controllers increases the directory service performance
significantly, although 32-bit domain controllers are still supported.
As in Exchange 2007, the recommended 4:1 ratio of Exchange processor cores to
global catalog processor cores (32-bit) still applies for Exchange 2010. If you have
64-bit global catalogs with enough memory to house the ntds.dit, the ratio increases
to 8:1. For example, if you have two Exchange servers with four processor cores per
server, you should have at least one global catalog processor core for Exchange 2010
server requests. As you cannot dedicate GCs to Exchange as the servers will deal
with requests from other applications, you need to make sure to deploy sufficient GC
capacity to deal with Exchange and the other applications.
If you’re planning to host Exchange servers for multiple domains at a single Active
Directory site you must include domain controllers from each domain you host
resources for. This ensures that a domain controller of their own domain is always
referred to your Outlook clients.
Exchange Server 2010 does not support Windows Server 2008 Read-Only-
Domain Controllers (RODCs) or Read-Only Global Catalogs (ROGCs) existing in the same
Active Directory site. If you are using RODCs or ROGCs, you cannot install Exchange 2010
in those Active Directory sites—you need to create separate ones for Exchange.
Exchange Environmental Considerations
Using Exchange Server 2010 on Member Servers
or Domain Controllers
You must also consider on which Windows 2008 server role you want to install Exchange
Server 2010: member servers or domain controllers. Even though Microsoft supports the
installation of Exchange Server 2010 on domain controllers, we strongly advise against it.
This is because you need to be a local administrator to manage an Exchange Server 2010
server, and local administrators will automatically receive Admin permissions on all of your
domain controllers.
In some circumstances, such as branch-office situations, you may not have a choice
because hardware is spare or budget is limited. We’ve seen situations where a single piece
of hardware held everything: domain controller, Exchange Server, and file and print services.
However, avoid that if possible. You can use virtualization to separate domain controllers
and Exchange servers easily when using virtualization such as Windows Server 2008 R2
Hyper- and still run everything on a physical computer.
As a protective feature, Dcpromo—the command to promote a Windows Server
2008 member server to a domain controller—cannot be run again after you have installed
Exchange Server 2010 on a Windows 2008 member server. After Exchange Server 2010 is
installed, changing the role from a member server to a domain controller or vice versa is
not a Microsoft-supported scenario.
Exchange Server Role Placement
To manage Exchange Server 2010 in a more natural way, server roles were implemented.
These roles enable administrators to easily choose which features should be installed on
an Exchange server. They provide the following advantages over the architecture used
in Exchange versions before Exchange 2007:
They reduce attack surface because only required roles are installed.
They allow you to install the servers for their intended role only.
They provide more possibilities for scalability and reliability.
They lower complexity to reduce system outages.
In Exchange Server 2010 you can choose from five server roles: Mailbox server, Hub
Transport server, Client Access, Unified Messaging server, and Edge Transport server.
Figure 3-8 provides an overview of all Exchange Server 2010 roles, their functionality,
and their connections.
Planning Exchange Server 2010 Placement
- Routing
- Policy
- Spam/Anti-Virus
Edge Transport
- Routing
- Policy
Hub Transport - SMTP
- Voice Messages
- Outlook Voice Access
Mailbox Unified Messaging
Client Access
- RPC Client Access
- Web Services
- Active Sync
- Mailboxes
- Public Folders
PBX/Telephone Carrier
FIGURE 3-8 Exchange Server 2010 roles
As you can see in the figure, you must follow certain rules to develop a plan of which
roles you place at which Active Directory sites. Table 3-8 provides an overview as well as the
main planning aspects for each role. More details about the Exchange Server 2010 roles are
covered in later chapters of this book.
TABLE 3-8 Exchange Server 2010 Roles and Planning Aspects
Mailbox Server
Hosts your mailboxes as well
as public folder databases.
You must plan to position
Exchange servers at the Active
Directory sites where most of
the users are located or
depending on your IT strategy
in key regional datacenters.
Because your users no longer
directly connect to the Mailbox
server in Exchange 2010
(only for public folder
access), you need to have at
least the Client Access and
Hub Transport server roles
available in the same Active
Directory site.
Exchange Environmental Considerations
Client Access
This role hosts RPC Client Access;
availability service and Autodiscover
for Outlook 2007 or later; Exchange
ActiveSync; client protocols such as
MAPI, POP3, IMAP4, Outlook Web
App (OWA), Outlook Anywhere and
Exchange Web Services (EWS).
Required in every Active
Directory site where a Mailbox
server is installed.
The recommendation is three
Client Access server processor
cores per four Mailbox
processor cores.
All client traffic flows through
the Client Access Server role in
Exchange 2010, including MAPI
connections from Outlook clients
that are handled by the RPC Client
Access layer.
Hub Transport
Manages all internal message
routing within the Exchange
organization and hosts transport
rules that can be applied to
messages. It also accepts all SMTP
types of messages even if they
come from the user.
Required in every Active
Directory site where a Mailbox
server is installed. In this Active
Directory site a global catalog
must be available.
Edge Transport
Acts as a smart host and SMTP relay
in your perimeter network and
handles all Internet-facing mail flow.
Provides anti-spam and antivirus
functionality. Provides address
rewriting and Transport rules to
protect the internal network.
Depending on the size of your
organization, you should plan
at least two Edge Transport
servers to provide redundancy
in case of problems.
Connects Exchange with your
telephone system or private branch
exchange (PBX) to provide voice
access to your mailbox.
Supports a maximum of 100
concurrent calls per server.
The planning aspect should
include the number of users
and how they use Unified
Messaging. A single Unified
Messaging server can host
approximately 3,000 users. You
need at least one Hub Transport
server available in the same site.
The rule of thumb regarding
sizing (with antivirus) is one Hub
Transport processor core per five
Mailbox server processor cores.
For redundancy reasons you
should have at least two Hub
Transport servers in larger
or critical Active Directory sites.
Planning Exchange Server 2010 Placement
Exchange Server 2010 server roles can coexist on a single Exchange computer with a few
rules to consider:
The Mailbox role, Hub Transport role, Client Access role, and Unified Messaging role
can coexist on a server.
On a Mailbox server that is member of a DAG, you cannot use Windows Network Load
Balancing (NLB).
Edge Transport cannot be shared with any other server role.
In a smaller organization you will probably end up having a server that hosts multiple
roles, mainly the Mailbox, Client Access, and Hub Transport roles. The larger the organization,
the more dedicated those server roles will get.
Planning Exchange Server Roles and Placement
Joe Cirillo
Senior Engineer and Architect, Horizons Consulting, US/Central Region
hen I prepare to install a new Exchange messaging system or integrate
with an earlier version of Exchange I always take the same approach.
Whether I am installing one physical server with multiple roles or installing
individual roles on dedicated hardware I always begin by first installing the Client
Access Server role.
Because the Client Access server is used by every mail client, you can fully prepare
the Client Access server for client access before installing the Mailbox server
role, thus ensuring that once the Mailbox server is online, users will be able to
successfully connect to their mailboxes based on your preconfigured settings.
When I prepare the Client Access server, I like to do the following:
If there will be a high volume of content conversion, move the %TMP% folder to
a dedicated set of drive spindles for improved performance.
Replace the self-signed certificate with a public certificate, typically a SAN
Create the necessary DNS records to support the services to be used.
Configure Exchange services for the Autodiscover Service.
Enable Outlook Anywhere.
Create a Client Access Array using EMS (new in Exchange 2010).
Configure the hardware load balancer.
Exchange Environmental Considerations
After I have fully configured and tested access and functionality of the Client
Access server, I install the Hub Transport role. This way I can ensure that message
transport is working properly. Again, having this role installed and configured
before the Mailbox server role will ensure that once I provision a mailbox to
a user, that user will be able to successfully send and receive e-mail messages.
When I prepare the Hub Transport server, I like to do the following:
Confirm that message tracking is enabled.
Change the location of the Queue Database and Queue Database Transaction
Logs for improved performance.
If necessary, modify the organizational level send and receive message size limits.
If necessary, modify the default receive connector to accept anonymous
If necessary, modify the default receive connector’s message size limit.
If necessary, create an additional receive connector for applications that require
relay access.
Configure remote domains.
Configure accepted domains.
Configure e-mail address policies.
Create send connectors.
If necessary, modify send connector message size limits.
Configure the hardware load balancer.
Once the Hub and Client Access servers are in place and properly configured I can
safely install the Mailbox server role, comfortable in the knowledge that my users
will be able to successfully connect to their mailboxes and send and receive e-mail.
When I prepare the Mailbox server, I like to do the following:
Change the file location of the default database and logs.
Create additional databases.
If necessary, modify mailbox database settings (storage limits, deleted item
retention, and so on).
If necessary, create a Public Folder database.
Configure the mailbox limits cache (see
Publish offline address books to the required distribution mechanisms
(public folders and/or Exchange File Distribution on a Client Access server).
Planning Exchange Server 2010 Placement
Control Outlook Access to Exchange based on client version.
Configure any settings required to enable high availability such as joining a
server to a DAG.
For designs that call for a distributed messaging infrastructure where Exchange
Servers will exist in multiple locations I still follow the basic guideline on installation
order of Client Access, then Hub, and then Mailbox. Again, this ensures that all
my services are working (even between sites) prior to provisioning a mailbox on
a Mailbox server.
Planning Network Port Requirements
When the first versions of Exchange came out, security was not a major consideration.
Of course, security was of concern in 1996 but the level of Internet connectivity that systems
have today, together with the threat posed by being connected to the Internet, make it
quite different. Obviously, this has changed in recent years. Windows Firewall is now a main
component of every Windows Server 2008 operating system. Windows Firewall basically
filters inbound and outbound traffic based on firewall rules. Exchange Server 2010 creates
the Windows Firewall rules to open the ports required during Exchange Setup—thus you
no longer need to configure these settings manually.
Some companies want to put certain server roles into a perimeter network. A perimeter
network is a network zone that is deployed between the Internet and a company’s intranet as
defense-in-depth and is protected by one or more firewall systems.
When defining your firewall ports, always consider the concept of
“less is more.” The fewer ports you allow to open, the more secure your system will be.
To provide an easy overview of the masses of ports, this section is organized according
to the Exchange Server roles. The tables are sorted according the required ports so you can
recognize which ports are used for which services or data paths.
For more information about firewall configuration see the Exchange Network Port
Reference at
Mailbox Server
The Mailbox server role hosts the mailbox and public folder databases. Apart from public
folders, the clients do not communicate directly with the Mailbox server but instead use the
Client Access server for communication that then establishes the connection to the Mailbox
server. For this reason it is not recommended to separate a Mailbox and Client Access server
with a firewall.
Exchange Environmental Considerations
Table 3-9 shows which ports are required for services or data paths to and from the
Mailbox server role. It’s important to understand that RPC traffic is always encrypted.
TABLE 3-9 Network Ports for Mailbox Role
Messaging application programming
interface (MAPI) access, Availability Web
service (Client Access to Mailbox server),
Content indexing, Recipient Update
Service RPC access (Exchange 2003 only),
Microsoft Exchange Active Directory
Topology Service access, Microsoft
Exchange System Attendant service
legacy access, Offline address book (OAB)
accessing Active Directory, Recipient
Update Service RPC access. RPC Endpoint
135/TCP (RPC)
Mailbox Assistants, Admin remote access
(remote registry), Microsoft Exchange
System Attendant service legacy access
135/TCP (RPC)
Clustering or DAG to communicate
between cluster nodes
(status and activity)
135/TCP (RPC),
3343/UDP + randomly
high TCP ports
DAG (Log shipping, seeding)
64327/TCP (customizable)
Active Directory access, DSAccess
to Active Directory
3268/TCP (LDAP GC),
88/TCP/UDP (Kerberos),
135/TCP (RPC Netlogon)
Microsoft Exchange System Attendant
service legacy access to Active Directory,
Recipient update to Active Directory
3268/TCP (LDAP GC),
88/TCP/UDP (Kerberos),
135/TCP (RPC Netlogon)
Admin remote access (SMB/File)
445/TCP (SMB)
Outlook accessing Offline Address
Book (OAB)
80/TCP, 443/TCP (SSL)
Yes (SSL)
Planning Network Port Requirements
Hub and Edge Transport Servers
Exchange Server 2010 includes two roles that perform message transport functionality: Hub
Transport server and Edge Transport server. You will need to consider this section when you
are planning to implement an Edge Transport server role in your organization. The Hub
Transport server takes care of messages that are routed within an organization; the Edge
Transport server role routes messages inside and outside of the organization. For that reason
Edge Transport servers are always placed in a perimeter network, whereas Hub Transport
servers are always installed behind the network perimeter and belong to the corporate
Table 3-10 explains which ports are required for services or data paths to and from the
Hub Transport and the Edge Transport server roles.
Because the Edge Transport server is designed to be located in the perimeter
network, it is assumed that only the communication between Hub Transport and Edge
Transport needs to be protected by firewalls. Of course, Edge Transport communication
to the Internet also should be protected if the Edge Transport server is located in the
perimeter network.
TABLE 3-10 Network Ports for Hub and Edge Transport Servers
Hub Transport server to Hub Transport
server, Hub Transport to Edge Transport
and vice versa, Edge Transport to Edge
Transport, Unified Messaging server to
Hub Transport server and vice versa
25/TCP (TLS)
Active Directory access from Hub
Transport server
3268/TCP (LDAP GC),
88/TCP/UDP (Kerberos),
135/TCP (RPC Netlogon)
Microsoft Exchange EdgeSync service
(from Hub to Edge)
50636/TCP (SSL)
Active Directory Rights Management
Services (AD RMS) access from Hub
Transport server
Mailbox server to Hub Transport
and vice versa
135/TCP (RPC)
Clients to Hub Transport server
(using SMTP)
25/TCP (SMTP) or
587/TCP (SMTP)
Yes for TLS
Exchange Environmental Considerations
As the table shows, encryption is the default in many situations. Hub Transport to Hub
Transport is encrypted by default using the Exchange server’s certificate. If no machine certificates
are available for your Exchange server, the system will use self-signed certificates for encrypting
the communication. The same is true for Hub Transport to Edge Transport communication.
If clients such as Windows Messaging directly communicate with the Hub Transport server,
the only encryption possible is TLS over SMTP.
Client Access Server
The Client Access Server role manages all client requests and communicates directly with the
Mailbox role. Therefore it is best practice not to separate Mailbox and Client Access Server
roles with a firewall but instead to keep them in the same network. Remember, Microsoft
doesn’t support a firewall being placed between Client Access and Mailbox servers.
Table 3-11 describes which ports are required for services or data paths to and from the
Client Access Server role.
TABLE 3-11 Network Ports for Client Access Servers
Active Directory access
3268/TCP (LDAP GC),
88/TCP/UDP (Kerberos),
135/TCP (RPC Netlogon)
Autodiscover service, Availability
service, Outlook Web App (OWA),
Outlook Anywhere, Exchange
ActiveSync, Client Access server
to Client Access server for
Exchange ActiveSync and OWA
80/TCP or 443/TCP (SSL)
Client Access server to Client
Access server for Exchange
Web Services (EWS)
443/TCP (SSL)
110/TCP (TLS) or
995/TCP (SSL)
143/TCP (TLS) or
993/TCP (SSL)
Client Access server to Unified
Messaging server
5060/TCP, 5061/TCP,
5062/TCP + a dynamic
Client Access server to Exchange
Server 2010 Mailbox server
135/TCP (RPC) +
dynamic ports
Planning Network Port Requirements
Client Access server to a Mailbox
server that is running Exchange
Server 2003 or before
80/TCP, 443/TCP (SSL)
Client Access server to Client
Access server (POP3)
995 (SSL)
Client Access server to Client
Access server (IMAP4)
993 (SSL)
When a Client Access server proxies POP3 requests to another Client Access server, the
communication occurs over port 995/TCP, regardless of whether the connecting client uses
POP3 and requests TLS or connects on port 995/TCP using SSL. The same applies to IMAP4
connections where Client Access Server always uses port 993/TCP to proxy requests.
When your Exchange 2010 Client Access server is communicating with an Exchange
2003 server, it is a best practice to use Kerberos authentication (disable NTLM and Basic
authentication) and configure OWA to use forms-based authentication.
Unified Messaging Server
The Unified Messaging server role is used to play voice messages to users using a IP gateway
or a IP PBX (Private Branch eXchange). This server role communicates to all other server roles
and is always placed in the organization’s internal network.
Table 3-12 explains which ports are required for services or data paths to and from the
Unified Messaging server role.
TABLE 3-12 Network Ports for Unified Messaging Servers
Active Directory access
3268/TCP (LDAP GC),
88/TCP/UDP (Kerberos),
135/TCP (RPC Netlogon)
Unified Messaging to Mailbox server
135/TCP (RPC)
Unified Messaging to Hub Transport
25/TCP (TLS)
Exchange Environmental Considerations
Unified Messaging to Client
Access server
5075/TCP, 5076/TCP,
Unified Messaging to Client
Access server (Play on Phone)
135/TCP (RPC)
Unified Messaging to private branch
exchange (PBX)
5060/TCP, 5065/TCP,
5067/TCP (unsecured)
or 5061/TCP, 5066/TCP,
5068/TCP (secured)
and a dynamic TCP and
UDP port
Unified Messaging Web Service
80/TCP, 443/TCP (SSL)
International Considerations
You need to consider certain areas when implementing Exchange 2010 in a global,
heterogeneous, or multi-language environment. This section considers the most important
factors of a global implementation: the language, time and message format, and message
text encoding factors.
Multiple Language Support for Exchange
An important factor in international implementations to consider is the language for
Exchange that should be installed. By default, Exchange Server 2010 only includes the English
language for Exchange, but optionally you also can install additional language bundles.
If you install from the Exchange 2010 DVD, most of the language packs are
automatically included.
Exchange 2010 comes with two different language bundles:
Language Pack for Exchange You need this if you want to provide a localized
version of the Exchange management tools (EMC and ECP) and OWA prompts for
a specific language. A language pack includes the names of the default folders, user
interface and layout, translated help text, and so on.
Unified Messaging Language Packs You need these when you want to provide
the Exchange Server 2010 Unified Messaging feature for a specific language.
International Considerations
Language Packs for Exchange
Depending on the Outlook Web App (OWA) languages you want to support, you need to
install the respective Language Pack for Exchange. This provides localized messages for the
users. It provides, for example, OWA in the local language on Client Access servers. On Mailbox
servers it provides the default folder names in that language. On Hub Transport servers it
provides key strings such as “Read”, “Not Read”, or “Undeliverable” in the local language.
The following are some general recommendations when using language packs:
Always consider applying language packs for Exchange to all Exchange roles of that
specific site. This is to prevent a mix of non-English and English strings in OWA and
Outlook for users who set their language to non-English.
You should deploy the language packs starting with your Mailbox servers.
After installing the Exchange language packs, restart the computer to complete the
installation of the language packs.
If no Exchange language pack is deployed, English will be the only language available
in Exchange and OWA, regardless of the operating system language.
You can find an overview of available language packs for Exchange 2010 at http://technet
If you want to install the full language pack bundle for Exchange, you can download it at
To add a language pack for Exchange after you’ve installed Exchange, you need
to run Setup from your CD, not by going through Control Panel. Basically you add the
language pack as though you were installing a new Exchange server.
What language packs are installed on an Exchange server? On a Client Access server that’s
easy to answer: You can see the language packs when logging on to OWA. On the Regional
tab, under Settings, select the Language drop-down menu.
On Hub Transport or Mailbox servers, this is a bit more complicated. You have to use
Regedit.exe and look into the \HKLM\Software\Microsoft\ExchangeServer\v14\Language
Packs key to see what languages are installed on that specific Exchange server, as shown
in Figure 3-9.
To remove a language you need to remove the entire key entry for that specific language
found under HKLM\Software\Microsoft\ExchangeServer\v14\Language Packs\Client.
The language codes follow the ISO 639-1 codes (as described at
wiki/List_of_ISO_639-1_codes) except where more specific languages (such as zh-Hant) or
specific cultures (pt-pt, for example) have been added. Be aware that removing languages
directly from the Registry may cause issues in future versions of Exchange.
Exchange Environmental Considerations
FIGURE 3-9 Identifying installed language packs in the Registry
Unified Messaging Language Packs
Unified Messaging Language Packs contain prerecorded prompts, grammar files, text
to speech (TTS) data, Automatic Speech Recognition (ASR) files, and Voice Mail Preview
capabilities for a specific language. They are only available for the Exchange 2010 Unified
Messaging role and thus should not be installed on other server roles.
Install the same UM language packs to all Exchange UM server roles located in the same
site. This will automatically provide the same language capabilities to all your users.
Because the UM language packs are continuously enhanced, you can download the latest
language packs at
Time, Time Zone, and Daylight Saving
Time zone settings on Exchange Server 2010 computers are similarly crucial to those
on domain controllers in your Windows environment. If the servers run out of time
synchronization, you will receive errors because Exchange assumes it is no longer working
correctly. The EMS uses Kerberos when users authenticate themselves when they create a
new Remote Windows PowerShell session. If Kerberos doesn’t work, users won’t be able to
authenticate and the session cannot be created. If the time is not set correctly, EMS will fail to
work. Every message is time stamped, so if message servers stamp the wrong time, this will
screw up operations like message tracking.
International Considerations
Time is stored internally by Exchange using the Coordinated Universal Time (UTC) time
zone to prevent issues from time conversions. All log files include the time in UTC format,
which is sometimes confusing.
It is important to make sure you synchronize your time accordingly. Exchange Server
2010 automatically synchronizes the time within the domain if the server is a member of
the domain. You therefore should configure your forest to synchronize the time. Detailed
steps can be found on the Configure the Windows Time Service on the Forest Root Domain
Controller Web page at
With Exchange servers that are not part of the domain like Edge Transport servers,
you need to take care. Best practice is to configure a time server for every Edge Transport
server that automatically receives the current time using the Network Time Protocol (NTP)
from a server in your organization or directly from the Internet. You can use the following
command to configure a NTP server:
net time /setsntp: <ntp server>.
In a multi-forest environment, make sure that the NTP servers you configured in each
forest synchronize the time between them or with the same source.
The Daylight Saving Time (DST) changes every year, so you are well advised to keep your
Exchange Servers during this time updated. You only need to consider this when you operate
multiple Exchange Servers in different time zones, or if you’re planning to do so.
Always enable the clock as a system icon on your taskbar; it helps prevent time
issues from happening. Enabling the clock will show you the current system time whenever
you log on to the server. You can immediately correct it if there is an issue.
Message Format and Encoding
Because binary files cannot be sent directly using SMTP, they need to be encoded into
a different message format. This is because SMTP messages can only consist of characters
with 7 bits (or ASCII printable), meaning that you need to translate all 8-bit characters into
7-bit characters to transfer them using SMTP. This process is called message encoding.
Exchange Server 2010 supports the following message encoding formats:
Uuencode (or UNIX-to-UNIX encoding) is one of the oldest encoding formats that
supports encoding binary data. Three bytes of the binary file (24 bit) are divided into
four of six bytes, and these six-byte values are associated with printable ASCII code.
Uuencode has been widely replaced by MIME, but you still might need it if you’re
communicating with native UNIX SMTP servers to overcome message conversation
MIME (or Multipurpose Internet Mail Extensions) is the most common encoding format
used today on the Internet. MIME nowadays is not only used by SMTP messaging,
Exchange Environmental Considerations
but also by protocols such as HTTP. With MIME it is possible to exchange information
about the type of messages (the content type) between the sender and the recipient of
the message. MIME also defines the art of coding (Content-Transfer-Encoding).
To encode non-text elements, Exchange 2010 uses by default MIME encoding. This coding
of non-ASCII characters is based on quoted-printable (QP) coding the binary data, typically
using Base64-coding. As mentioned in the “Mail Client Support” section that follows, some
UNIX or Linux clients cannot understand this message format and have issues with special
characters that are not part of ASCII, such as German vocal or Chinese character sets. In such
situations you might need to adapt the encoding format to solve the problem.
In addition to the encoding format, Exchange Server and Outlook use the Transport
Neutral Encapsulation Format (TNEF) as the file format for attachments in e-mail messages.
Attachments in this format often contain files called winmail.dat or win.dat. This format allows
Outlook users to use some advanced features, but message programs other than Outlook
cannot use it and receive an attachment called winmail.dat.
Mail Client Support
This section describes supported client and browser versions for Exchange 2010 and provides
a feature overview of Microsoft Office Outlook 2003, Outlook 2007, and Outlook 2010.
Microsoft Outlook/Entourage
Several client programs supporting Exchange 2010 are available. Outlook 2010 for Windows
and Entourage 2008 for Mac OS provide the most features for Exchange 2010 because
they are engineered by Microsoft to work together well. Thus they include features such
as MailTips that maximize the use of Exchange functionality. Because they are available
in different versions, the following list provides an overview of the supported clients for
Exchange Server 2010:
Microsoft Outlook 2003 or later on Windows including the latest Service Pack
Microsoft Entourage 2008 SP2 EWS or later on Mac OS
Microsoft Outlook on Mac OS (2010 release)
Because of the functional change in Exchange 2010 whereby Outlook no
longer communicates directly to the Mailbox server, Outlook 2002 (which was part of
Office XP) and earlier versions cause weird issues when connected to Exchange Server
2010. I personally tested Outlook 2002 with Exchange 2010 and some features were
not working correctly; consider migrating any Outlook 2002 users before moving their
mailboxes to Exchange 2010. Also, Microsoft does not support Outlook 2002 or earlier
for Exchange 2010.
Mail Client Support
Each version of Outlook supports different features with Exchange Server. To receive the
most server-based features, you will need to use the latest Outlook Version: Outlook 2010.
Table 3-13 provides feature guidance on Exchange 2003, Exchange 2007, and Exchange 2010
and which features are available in which version of Exchange Server.
TABLE 3-13 Outlook Feature Comparison by Exchange Server Version
2003 (SP2)
2007 (SP1+)
2010 (RTM)
Push e-mail
Calendar (on server)
Free/Busy information
Free/Busy details
Scheduling assistant
Contacts (on server)
Contact sharing
Calendar sharing
Calendar publishing
Archive access
Orgizational hierarchy
GAL access
Conversation view
Conversation actions
(ignore/move always)
UM (Voice mail)
UM preview
Protected Voice Mail
Managed folders
Tasks (on Server)
Public folders
Notes (server stored)
Exchange Environmental Considerations
2003 (SP2)
2007 (SP1+)
2010 (RTM)
IRM protected messages
Policy management
(group policy)
Offline address book
External/Internal OOF
OOF Scheduling
Voting Buttons
Search folders
Favorites folders
Journal (on Server)
RSS Feeds (on Server)
Custom forms
Custom dictionaries
Mail rules
Consider Outlook RPC encryption
Ross Smith IV
Senior Program Manager, Exchange Server Product Group, Microsoft Corporation
ecause Exchange Server 2010 requires Outlook traffic to be RPC encrypted,
you might run into issues if you already have Outlook 2003 or Outlook 2007 in
place today. By default, Outlook 2003 and Outlook 2007 do not use RPC encryption,
so you will need to enable it before they’re able to connect to an Exchange Server
2010. For details on how to prepare for this situation, you can find more information
Mail Client Support
Outlook Web App
Exchange Server 2010 also supports various browsers not only in Outlook Web App Light but
also with the Outlook Web App Premium edition that also provides rich features to browser
users. OWA Premium includes features such as drag-and-drop, Junk-Mail filter configuration
or voicemail configuration options that are not available in OWA Light. For Outlook Web App,
the following browsers are supported:
Outlook Web App Premium on Microsoft Windows Vista or later Internet
Explorer 7 or later, Firefox 3.0.1 or later, Google Chrome or later
Outlook Web App Premium on Apple Mac OS X Safari 3.1 or later, Firefox 3.0.1
or later
Outlook Web App Premium on Linux Firefox 3.0.1 or later
Outlook Web App Light Almost any other browser or operating system
Even though browsers that run on operating systems other than Windows support
Outlook Web App Premium, remember that it still has some limitations. For example, if you
want to use the S/MIME control provided by Exchange for digital signatures or message
encryption in Outlook Web App, you need to run Internet Explorer and Windows.
A full list of browsers that support Outlook Web App can be found at http://help.outlook
IMAP and POP3 Clients
Exchange Server 2010 also provides support for IMAP and POP3 protocols. Any IMAP4/POP3
client (such Outlook Express or Thunderbird) can be used. However, you need to consider that
some native IMAP or POP3 clients such as MailX have problems with the Microsoft internal
content-encoding. By default Exchange 2010 converts the content of message attachments
to quoted-printable (QP) format. If you client has issues reading it you might need to use
a different client. Most of the Windows or Mac OS IMAP/POP3 clients do not cause issues, but
for some in the area of LINUX such as MailX you need to consider this.
Additional Resources
Windows Server 2008 R2 Components:
How to disable certain Internet Protocol version 6 (IPv6) components in Windows
Vista, Windows 7 and Windows Server 2008:
IPv6 for Microsoft Windows FAQ:
Exchange Environmental Considerations
Outlook Anywhere Scalability with Outlook 2007, Outlook 2003, and Exchange 2007:
Exchange Load Generator 2010 Beta (64 bit):
Sysinternals BgInfo Tool:
Active Directory Logical Structure and Data Storage:
Monitoring and Troubleshooting Active Directory Replication Using Repadmin:
The official Microsoft support statement for Exchange 2010 and SLD/Disjoint/
Non-contiguous Namespaces:
DNS Requirements for Installing Active Directory:
Language packs for Exchange 2010:
Language pack bundle for Exchange 2010:
Language codes as defined in ISO 639-1 codes:
Exchange Server 2010 UM Language Packs:
Configure the Windows Time Service on the Forest Root Domain Controller:
Wikipedia information about Microsoft Office 2010 for Mac OS X: http://en.wikipedia
Exchange 2010 Outlook Web App Supported Browsers:
Additional Resources
Designing Exchange
Server 2010
Client Access in Exchange 2010
Routing and Transport
Mailbox Services
Edge Transport and Messaging Security
Automated Message Processing, Compliance,
and Archiving 345
Unified Messaging
Federated Sharing
Designing High Availability
Backup, Restore, and Disaster Recovery
Hardware Planning for Exchange Server 2010
Client Access
in Exchange 2010
Client Access Server Architecture 139
Planning Client Access to Exchange 158
n this chapter the various aspects of designing the Client Access Server role are
described, starting with an in-detail explanation of the Client Access Server role
including the RPC Client Access layer and the provision of the Availability and
AutoDiscover services. This chapter will provide design guidelines for designing Client
Access services with Exchange Server 2010, and will provide best practices for installing
the Client Access Server role.
Client Access Server Architecture
You can already guess by looking at the name of this Exchange Server role that it enables
a mailbox-enabled user to gain access to his or her mailbox using any of the supported
Client Access protocols: MAPI/RPC, POP3, IMAP4, HTTP, and Exchange ActiveSync.
Client Access Server Features
The Client Access Server role has grown from previous versions. Microsoft introduced
the Client Access Server role in Exchange 2007 to replace the previous situation where
all mailbox clients either directly connected to the mailbox server or via a proxy.
The mailbox server did all of the logic and rendering of data. A major architectural
change came in Exchange 2007 and most of the Client Access protocols were
consolidated on the Client Access Server. This included Outlook Web Access (OWA),
IMAP4, POP3, Exchange Web Services, and Exchange ActiveSync. MAPI and WebDav
clients still connected to the mailbox server directly.
Now in Exchange 2010, all business logic and data rendering takes place on the
Client Access Server. Figure 4-1 illustrates all of the middle-tier services provided by the
Exchange 2010 Client Access Server.
Administration and
Exchange Web Services
Control Panel
Client Access
Client Access
Outlook Web
FIGURE 4-1 Client Access Server role
Along with this new architecture, the Client Access Server hosts a number of new features,
as shown in Table 4-1.
TABLE 4-1 Client Access Server Features
Outlook Web App
Outlook Web App enables Web-based clients to access
their mailboxes.
RPC Client Access
RPC Client Access enables MAPI clients to access their
mailboxes (such as Microsoft Outlook).
POP3/IMAP4 enables clients such as Windows Live Mail
to access their mailboxes.
Outlook Anywhere
Outlook Anywhere enables Microsoft Outlook 2003
or later clients to access their mailboxes using HTTP(S).
ActiveSync enables mobile phones running Exchange
ActiveSync to synchronize e-mail, contacts, calendar
information, and tasks to the device.
Availability Service
The Availability Service provides clients with free/busy
Exchange Web
Services (EWS)
Exchange Web Services provides an XML/SOAP interface
for programmatic access to Exchange Server functionality.
Client Access in Exchange 2010
MailTips analyzes message properties, including the
recipients, and notifies users of potential issues with the
message before it is sent.
Exchange Control
Panel (ECP)
The Exchange Control Panel is a Web-based management
interface that allows administrators access to a set of
administrative tasks. ECP also provides user self-service
AutoDiscover enables Outlook 2007 and Outlook 2010
clients and Windows Mobile 6.1 or later clients to
auto-configure user profile settings.
Address Book Service
The Address Book Service replaces DSProxy for handling
directory-related requests.
Windows Services
Table 4-2 lists the Exchange services added to Windows when the Client Access Server role is
TABLE 4-2 Exchange Services for the Client Access Server role
Microsoft Exchange
Active Directory
This service reads information from
all Active Directory partitions. The
data is cached and then used by
Exchange 2010 servers to discover
the Active Directory site location of all
Exchange services in the organization.
It is also responsible for updating the
site attribute of the Exchange server
object in Active Directory.
Runs on all Exchange
servers except Edge
servers. Stopping
this service is the
quickest way to stop all
Exchange services.
Microsoft Exchange
Address Book
This service manages client
address book connections and is
dependent upon the Microsoft
Exchange Active Directory
Topology service.
This service is required
to register the Client Access
server as the Name Service
Provider Interface (NSPI).
This performs all directory
connections for clients.
Microsoft Exchange
File Distribution
This service is responsible for
distributing the offline address
book (OAB) files, unified messaging
prompts, and group metrics files. This
service is dependent on the Microsoft
Exchange Active Directory Topology
and Workstation services.
This service is required to
distribute the OAB files
from the OAB generation
server to the Client Access
server distribution points.
Client Access Server Architecture
Microsoft Exchange
Provides forms-based
authentication to Outlook Web
App and the Exchange Control
Panel. This service has no
If this service is stopped,
OWA and ECP users
cannot authenticate.
Microsoft Exchange
Provides IMAP4 service to users.
This service is dependent on the
Microsoft Exchange Active
Directory Topology service.
This service is set to
Manual by default. It
must be set to Automatic
if IMAP4 clients are
connecting to this Client
Access server.
Microsoft Exchange
Mailbox Replication
This service processes mailbox
move requests and is dependent
on the Microsoft Exchange Active
Directory Topology service and
the Net.Tcp port-sharing services.
This is an optional
Microsoft Exchange
This service allows applications to
call the Exchange diagnostic cmdlets.
It has no dependencies.
This service should
be started when you
consider implementing
monitoring tools such
as System Center
Operations Manager.
Exchange POP3
Provides POP3 service to users.
This service is dependent on the
Microsoft Exchange Active Directory
Topology service.
This service is set to
Manual by default. It
must be set to Automatic
if POP3 clients are
connecting to this Client
Access server.
Exchange Protected
Service Host
Replaces services from the System
Attendant functions in previous
versions of Exchange.
Microsoft Exchange
Service Host
Used to do GroupMetrics
calculations for MailTips and
ensures ValidPorts registry keys for
Outlook Anywhere.
Microsoft Exchange
RPC Client Access
This service manages client RPC
connections and is dependent on
the Microsoft Exchange Active
Directory Topology service.
Client Access in Exchange 2010
This is a required
service for MAPI clients
to connect to their
mailbox data.
New Features
This section introduces several of the new or improved Client Access Server features.
Outlook Web App (OWA)
OWA has been renamed from Outlook Web Access in previous versions of Exchange. OWA
allows users to access their mailboxes using a large number of Web browsers, including
Internet Explorer 6.0+, Firefox, Safari, and Chrome. As with each new version of Exchange
Server, OWA includes more enhancements and comes even closer to the full client experience.
The following list highlights several of the new features:
Conversation View
Instant Messaging Integration with OCS 2007 R2
Predefined Search Filters for quick search of folder contents
Enhanced Right-Click
Attach messages to messages
Another notable change is with OWA policies. Past versions of Exchange applied OWA
policies against the IIS virtual directory. In Exchange 2010, the policy settings are now
created at a global level, and can be applied per user. A default policy is created during role
installation, but it is not applied to any mailboxes. The default policy enables all the options.
OWA policies can be applied during a new user creation, or later on with the Set-CasMailbox
cmdlet or EMC.
Service Pack 1 introduces a new look and feel to simplify the UI and provide a clean
view that emphasizes content. The new interface scales well with different screen sizes
and resolutions, particularly for Netbooks. Figure 4-2 shows an example of the new interface.
Client Access Server Architecture
Part of the new OWA experience is an updated options menu. The most frequently
accessed options are now displayed in a drop-down menu, as shown in Figure 4-3.
Additionally, users now have the ability to apply a theme to OWA.
FIGURE 4-3 OWA themes
A very welcome addition in Service Pack 1 is the ability to print custom calendars in OWA.
Users can view a printable calendar in Daily/Weekly/Monthly/Agenda views.
RPC Client Access
One of the major new architectural changes in Exchange 2010 is how RPC (or MAPI) clients
access their mailbox and directory information. Figure 4-4 illustrates the new Exchange 2010
RPC architecture.
Directory Server
Client Access
Mailbox Server
FIGURE 4-4 RPC Client Access changes
Client Access in Exchange 2010
Previously, RPC clients such as Microsoft Outlook made a connection directly to the
server running the Mailbox role. In Exchange 2010, the Client Access Server handles the task
of processing all RPC requests in place of the Mailbox server. This is not 100-percent true
because public folder connections still require direct connections to a Mailbox Server role
after being authenticated with the Client Access Server, but these connections still use the
Microsoft Exchange RPC Client Access Service on the Mailbox server.
These changes result in several benefits. The first advantage is that all Client Access uses
a common route for mailbox access shown in Figure 4-5. This allows for consistent application
of business logic and rules regardless of the client. Previously, clients either behaved
differently or redundant code sat on multiple tiers. Features that take advantage of change
include the Calendar Repair Assistant and the content conversion code.
EWS-Based Third-Party
Exchange Services:
EWS, ActiveSync, Unified
Messaging, OWA, Agents
Middle Tier
Outlook and MAPI
NSPI (Directory)
Exchange Business
Exchange Core Business Logic
FIGURE 4-5 Middle tier
Client Access Server Architecture
The second benefit of channeling client connections through a common path is that
it makes more efficient use of network connections, and provides better scaling (more
users per mailbox server). Using a 64-bit operating system allowed Exchange 2007 to scale
better than previous versions. Removing the traditional bottlenecks (such as memory)
allowed new bottlenecks to appear. TCP connections became a limiting factor when trying
to scale mailbox servers to large numbers of users. A connection is made up from the
source IP address, source port, destination IP address, and destination port. A common
issue occurred between the Client Access server and the Mailbox server. On Windows 2003,
the Client Access server can use only a single source port per IP address when making an
outbound connection to another computer. After the source port has been used, it is not
available for any other outbound connections on the server. This becomes an issue when
large numbers of connections are required, such as when Outlook Anywhere is heavily used.
This was addressed in Windows 2008 by allowing the source port to be used once per source
IP address. By adding additional IP addresses, the Client Access server could scale past 60,000
connections. However, DSProxy—used to provide directory access to Outlook clients when
connected over Outlook Anywhere—did not take advantage of this change, and was still
limited to 60,000 outbound connections to global catalog servers. Figure 4-6 shows the
Exchange 2007 connection architecture and where the TCP connection limitations were.
Outlook Anywhere
Client Access
60,000 Outbound Mailbox Servers 60,000 Outbound
TCP Connections
TCP Connections per
per Mailbox Server
Client Access Server
NIC (Windows 2008)
RPC Access
~65,000 TCP Connections
per Mailbox Server
Mailbox Servers
FIGURE 4-6 Exchange 2007 Client Access scale
Compare this to the Exchange 2010 situation shown in Figure 4-7. The Client Access
server now disconnects the user’s connection and saves its session state information. Instead
of maintaining a connection for each user between the Client Access server and Mailbox
server, there is a shared pool of 100 connections. If the user’s connection is not active, it
just stays in a disconnected state. This design allows for the Client Access server to scale
better without having to add additional NICs. The number of shared connections is not
Client Access in Exchange 2010
configurable or exposed to administrators, and Microsoft did significant testing during
product development that suggests companies will not need to change this value. Even
though Figure 4-7 shows a Client Access Array, this mechanism operates in the same way with
a single Client Access server.
Client Access Server Array
100 Shared
Directory Servers
Mailbox Servers
FIGURE 4-7 Exchange 2010 Client Access Scale
This architectural change also impacts directory access. The Client Access server now
implements the Address Book Service to replace the DSProxy interface on servers with the
Mailbox role. In Exchange 2000 through 2007, DSProxy was a true proxy and the global
catalog provided the NSPI endpoint when clients connected using Outlook Anywhere. In
Exchange 2010, the Client Access server is the endpoint and makes calls on behalf of the client
to the global directory. Why the significant change? The DSProxy implementation caused a
few issues. One concerned Outlook Anywhere and split connections, described in detail later
in this chapter. At a high level, split connections could cause a user with Outlook Anywhere to
end up with directory service calls being dropped.
Another common issue was that Outlook frequently connected to a domain controller that
did not hold a writable copy of a group that users wanted to manage so they got errors when
trying to perform group management. Several changes were implemented over the years to
address multi-domain DL updates, but the only completely effective solution was to move
all users and distribution lists to the same domain. For most companies, this is simply not
possible, so they end up creating a complete group management portal, or using operations
processes to control user requests. The Address Book Service detects modification of DL
membership, delegate management, and certificate management and calls the appropriate
cmdlets to make the necessary changes on a domain controller that has a writeable copy
of the object. The service uses RBAC security to ensure that the user has the required
permissions to make the change. Another great benefit of the Address Book Service is that
future reads from the client session go to the same domain controller and the change is
reflected immediately.
Previously, users hidden from the Global Address List (GAL) could not create profiles. The
changes in Exchange 2010 also solve this known issue. Now, users can create a profile whether
or not they are hidden from the GAL.
Client Access Server Architecture
Finally, moving Client Access helps with faster and more seamless failovers, because the
client maintains a connection with the Client Access server, the client is not aware of which
mailbox server is hosting the active database. Therefore, it is possible to failover a single
database instead of requiring the entire storage group, as in Exchange 2007. Microsoft’s
target failover time before users are reconnected to their mailboxes in Exchange 2010 is fewer
than 30 seconds; CCR was about 2 minutes.
Exchange Control Panel
The Exchange Control Panel (ECP) is a completely new Web application. For end users,
it provides a way to configure mail options, as shown in Figure 4-8. ECP is not only used
seamlessly with OWA, but it is also used in Outlook 2010 when a user manages voicemail
FIGURE 4-8 ECP user options
ECP is not only for end users, but is also used by administrators for organization-level
management. Figures 4-9 and 4-10 show some of the functionality provided to
administrators. Figure 4-9 illustrates how an administrator can create and edit mailboxes,
create groups and contacts, and administer roles. Service Pack 1 adds support for Syndicated
Admins. Prior to Service Pack 1, administrators must have a mailbox to access ECP. With
Syndicated Admins it is now possible to log on to ECP without having a mailbox. For example,
you can use the Add-RoleGroupMemeber cmdlet to grant an administrator account to the
‘OrganizationConfiguration’ role. This admin account does not have a mailbox, but is able to
open the ECP and perform administrative operations. Pre-SP1, if the account did not have
a mailbox, the Add-RoleGroupMember cmdlet would fail. This is useful for companies that
require administrators to have two accounts for security role separation and do not want
administrative accounts to be mail-enabled.
Client Access in Exchange 2010
FIGURE 4-9 ECP management
Figure 4-10 shows an example of the new multi-mailbox search feature that allows users
who have the Discovery Management role to perform searches based on keywords or other
FIGURE 4-10 Exchange Control Panel Multi-Mailbox Search
Exchange ActiveSync
Exchange ActiveSync (EAS) is the Exchange feature that syncs mailbox information with
mobile phones. Mobile clients can sync e-mail, contacts, calendar data, and tasks. Microsoft
has licensed ActiveSync technology to other mobile phone manufacturers, such as Apple Inc.,
Client Access Server Architecture
Nokia, Palm, Google, and Sony Ericsson. It is up to the licensee to decide which features of
the ActiveSync protocol to implement.
One feature of ActiveSync is DirectPush technology. DirectPush allows the mobile phone
to maintain a connection to Exchange and receive updates in real time as opposed to polling
the server for new mail.
Exchange 2010 includes the ability to generate ActiveSync Reports. An administrator
runs the Export-ActiveSyncLog cmdlet to generate a report with the following information
Exchange ActiveSync Usage Report Used to give information related to total
bytes sent and received, item counts, and item types.
Hits Report Used to see the total number of sync requests per hour, and number
of unique devices syncing.
HTTP Status Report Used to summarize the overall performance of the Client
Access server.
Policy Compliance Report Reports on the number of fully compliant, partially
compliant, and non-compliant devices syncing with the organization. Compliancy
depends on the level of enforcement the mobile device implements.
User Agent List Reports the total number of unique users sorted by the mobile
phone’s operating system.
Administrators now have access to a wealth of information that helps with capacity
planning and service level management.
Another great advancement since Exchange 2007 is the security policies for mobile
devices. In Exchange 2007, an administrator has the ability to define a security policy
and enforce the policy on a per-user basis. This is problematic for users who use multiple
devices because the policy affected every device. If not all of the user’s devices fully enabled
all of the security features, the user would have to either have all devices enabled or no
devices enabled. Exchange 2007 gave administrators control at the device level, using
deviceID to define ActiveSync device access rules. Exchange 2010 expands this functionality
with several new capabilities. An administrator can define the default action for when a new
device attempts its initial sync. The possible actions are to allow, block, or quarantine the
device. If an administrator configures quarantine, the user receives a notification that the
request for device syncing is being reviewed, while the administrative account configured
will receive notification to approve the request. You configure this feature with the
Set-ActiveSyncOrganizationSetting cmdlet with the DefaultAccessLevel and
AdminMailRecipients parameters. You can then configure specific device policies that
override the default by using the new-ActiveSyncDeviceAccessRule cmdlet. In Service Pack 1,
administration of policies and devices was added to the ECP. Again, you must set the access
level. Additionally the rule can be based on the following characteristics:
Device model
Device type
Device operating system
Device user agent
Client Access in Exchange 2010
Users and administrators can view this information for existing ActiveSync partnerships
using OWA to view the mobile phone details. For example, a phone partnership may show
the following:
Device Name: Touch Pro
Device Model: HTC Touch Pro T7272
Device Type: PocketPC
Device OS: Windows CE 5.2.19965
Device User agent: MSFT-PPC/5.2.19965
The administrator can use this information to build a policy specific to this device type,
name, and so on. For example, if the administrator wants to always allow PocketPC device
types under any circumstance, she would use the following cmdlet:
New-ActiveSyncDeviceAccessRule –QueryString PocketPC –Characteristic
DeviceModel –AccessLevel Allow
With this policy in place, all PocketPCs will be allowed to sync regardless of specific
features the phone supports. Currently, these policies can only be managed through EMS
cmdlets. The default ActiveSync policy allows any device to synchronize.
Internet Calendar Sharing
An interesting new feature in Service Pack 1 is for the ability to share calendars externally
without federation. Similar to federated sharing, an administrator must enable and configure
the feature to be available. Once enabled, users can share their calendar with anyone through
OWA. By default, Internet Calendar Sharing is disabled. There are two types of URLs that can
be published: restricted and public. With restricted URLs, the URL is obfuscated and must be
sent to the external user directly. Public certificates, on the other hand, can be searchable on
the Internet. This is shown with examples in Table 4-3.
TABLE 4-3 Internet Calendar URLs
[email protected]/
Public[email protected]/
Additional security measures are in place to protect Exchange because this feature exposes
data to anonymous external users. First, the feature was created with total isolation from
other Exchange resources. Sharing was implemented with a dedicated virtual directory.
Second, the application uses a separate application pool. Third, the http access is limited to
the dedicated virtual directory. Finally, throttling is enabled to prevent excessive resource
consumption. Requests are throttling both on requests per mailbox and limits on CPU
utilization per Client Access Server.
Client Access Server Architecture
Client Access Throttling Policies
At times, clients consume server resources to the point where everyone is affected. For
example, some third-party search programs can send a large number of RPC requests when
they perform indexing. The sheer number of RPC requests from these clients can cause
performance problems on the backend. Exchange 2010 uses client-throttling policies to
prevent this situation. A default client-throttling policy is configured when the Exchange
organization is created. The default policy can be customized or additional policies can be
created. The default policy settings are shown in Table 4-4. Do not make changes directly to
the default policies—create a copy of the default and make the changes to the new policy.
This will enable an administrator to quickly revert back to defaults if the need arises.
TABLE 4-4 Default Client-Throttling Policy Settings
The number of concurrent connections
an ActiveSync user can have running
The number of concurrent connections
an Exchange Web Services user can
have running concurrently.
The length of time, in seconds, searches
made by EWS run before timing out.
The number of concurrent connections
an Outlook Web App user can have
running concurrently.
The number of concurrent connections a
POP3 user can have running concurrently.
For Remote Windows PowerShell
users, the number of remote Windows
PowerShell concurrent sessions. For
Exchange Web Services, the number
of concurrent cmdlet executions that
a user can have at the same time.
The number of concurrent connections
an RPC Client Access user can have
running concurrently.
The per-process CPU percentage at which
users begin to be backed off.
It is a best practice to make sure that no throttling policy parameters are set to
$null (no limit). This prevents users from unintentionally placing a high load on the server.
Client Access in Exchange 2010
BlackBerry and Performance Impacts
Robin Thomas
Program Manager, Exchange Mailbox, Microsoft Corporation
oon after Exchange 2010 was released, customers who used RIM BlackBerry
Enterprise Server (BES) discovered that BlackBerry devices may experience some
issues caused by the new throttling functionality. For example, users who made
a change to calendar items, such as deleting an appointment, would not have that
change replicated to Exchange. Also, if a BlackBerry user was sent a meeting invite,
it would not show up on the device. To fix this issue, you need to disable client
throttling. Although disabling throttling completely will certainly fix the problem,
you are giving up a lot of protection from this new feature. A better solution is to
create a new policy and assign it only to the BES service account. You can create and
apply the appropriate throttling policy for the BES service account by typing these
two commands into EMS.
1 . New-ThrottlingPolicy BES –RCAMaxConcurrency $null -RCAPercentTimeInCAS
$null –RCAPercentTimeInMailboxRPC $null –RCAPercentTimeInAD $null
2. Set-Mailbox BESAdmin –ThrottlingPolicy BES
BES is the name of the throttling policy and can be anything. BESAdmin is the BES
service account.
At this point, you can run Get-ThrottlingPolicy BES to see the details. BES servers
access Exchange using RpcClientAccess service, so the only values that are relevant
here are RCA*.
For Exchange 2010 RTM, a second configuration change is required for BlackBerry
Enterprise Servers to work correctly. In Exchange 2010 SP1 and later, this
configuration is covered via the previously-mentioned throttling policy. By default,
Exchange only allows 50 concurrent address book connections. The BES account
makes lookups on behalf of the users, so you may exhaust this connection limit
very quickly. RIM recommends changing the MaxSessionsPerUser value to 100,000
(this is located in the file).
Unfortunately, unlike the throttling policy, you cannot configure this setting per
user, so it will raise the limit for all users. You may want to start with a smaller
number and increase as your number of BlackBerry devices increases.
For more information, visit RIM’s Web site for configuring the BlackBerry
Enterprise Server with Exchange 2010 help document:
Client Access Server Architecture
Service Pack 1 includes several improvements for client throttling. In RTM code, the
client that has been throttled will end up with failed requests. This can result in poor user
experience. Take, for example, an Entourage client that is syncing a mailbox and is constantly
going over budget. Any other user requests, such as a name resolution, will also fail. In Service
Pack 1, however, instead of failing requests, the request is added to an asynchronous queue
that will delay processing. This sleep time is equal to a backoff time plus 1 millisecond. At the
time of this writing, the backoff time had not been finalized. For batch operations, processing
will pause until the caller has regained 1 millisecond of budget. Then, processing will continue
starting with the item left off, and it will stream the items back to the caller as they are
MailTips is a very useful new feature that will make a lot of users happy. It is important to
first understand the feature before we look at the mechanics and performance impact of
turning it on.
How many times have you sent an e-mail only to receive an out-of-office notification?
MailTips provides feedback while composing a message, before you hit send. Figure 4-11
shows an example of an e-mail with two informational messages. MailTips lets the user know
that he is sending mail to a distribution list that has a large number of members. Also, Jeffrey
is out of the office, so the user may want to send the message to one of Jeffrey’s peers.
FIGURE 4-11 MailTips example
Keep in mind that MailTips is not a security measure, meaning that is does not prevent
users from taking action. Rather, the MailTips feature only provides useful information to help
users make better decisions before hitting Send. There are a number of prebuilt MailTips, as
listed in Table 4-5.
TABLE 4-5 Exchange 2010 MailTips
Invalid Internal
Informs the user that
a user does not exist
for an e-mail address
within the organization.
Active Directory
Mailbox Full
A recipient has a full
Mailbox Store
Automatic Replies
A recipient has an
automatic reply enabled
(such as out-of-office).
Mailbox Store
Client Access in Exchange 2010
A recipient has a custom
MailTip enabled.
Active Directory
A recipient has a mail
delivery restriction
Mailbox Store
A recipient is external or
part of a distribution list.
Group Metrics
Large Audience
A distribution list
contains more than 25
members (configurable).
Group Metrics
A recipient is enabled for
on BCC
The user replies all to a
message on which he or
she was bcc’d.
Oversize Message
The message is larger
than the organizational
limit, maximum send size
on the user’s mailbox,
maximum receive size on
the recipient’s mailbox, or
maximum request length
setting for OWA.
MailTips are triggered by the mail client during one of the following operations:
Adding an attachment
Adding a recipient
Reply or Reply-All
Opening a message from the Drafts folder
MailTips processing occurs in a background thread, so it will not impact the user working
with their message. In other words, users do not have to wait for MailTips to finish processing
before they send a message, if that is what they want to do.
Figure 4-12 provides a deeper look at the MailTips architecture. The source for MailTips
data comes from Active Directory, Exchange Mailbox Server, and Group Metrics data.
The Groups Metrics process is responsible for collecting and recording information about
the size of distribution lists and external recipients. This information is used for the external
recipient and large audience MailTips.
Client Access Server Architecture
Active Directory
Exchange File
Distribution Service
Client Access
Group Metrics
Offline Address Book
Mailbox Server
FIGURE 4-12 MailTips architecture
Groups Metrics generation happens by default on the Mailbox server that is responsible
for creating the OAB and can be assigned to another Mailbox server, which is important
in a large organization. On Sunday, a full generation runs for every group (both static and
dynamic) within a random time two hours from midnight. Each day, the process will generate
incremental results. The day for full generation is hard-coded, but the generation time can
be set using the set-mailboxserver property named GroupMetricsGenerationTime (24-hour
format). If you change the GroupMetricsGenerationTime property, the next generation occurs
according to the old schedule. Subsequent generations will start at the new time. You can
force regeneration by restarting the Microsoft Exchange Service Host service or rebooting the
server. The process creates files by default in the <Exchange_Install_Path>\GroupMetrics. The
files created are shown in Table 4-6.
TABLE 4-6 GroupMetrics Files
Binary file containing the membership and
external members count
XML file containing information about the Group
Metrics generation server
Plaintext file containing the list of groups that were
updated since the last time Group Metrics was run
Client Access in Exchange 2010
Every eight hours, the Microsoft Exchange File Distribution Service on the Client Access
server builds a list of Mailbox servers that have Group Metrics generation enabled. By
default, the organizational configuration setting for Group Metrics is enabled. This means
that Group Metrics will be generated on every mailbox server that generates an OAB and
will also generate Group Metrics data and be included in the list. In addition, the list includes
mailbox servers that are explicitly enabled for GroupMetrics generation. The property
GroupMetricsGenerationEnabled is used to manually enable generation for a Mailbox server
and is set to false by default. After the list is created, the Client Access server will pull the
Group Metrics data from the best server. The best server is based on Active Directory sites
and link costs. One option is to leave GroupMetricsGenerationEnabled set to false and let
the Client Access server use the OAB topology. This is one less topology that needs to be
designed and maintained. For organizations that do not use OABs or need more control, the
option still exists to create your own topology.
To support offline clients, the OAB was extended to have MailTips data. Table 4-5 lists
which MailTips are available offline.
The process for evaluating MailTips is shown in Figure 4-13.
FIGURE 4-13 MailTips evaluation process
The mail client makes a request to the local Client Access server.
The Client Access server retrieves data from Active Directory and reads the Group
Metrics data (locally).
For local recipients in the message header, the Client Access server queries the
Mailbox server.
For each remote recipient, the Client Access server makes a request to the remote
recipient’s Client Access server.
Client Access Server Architecture
The remote Client Access server makes RPC requests for data from the remote
Mailbox server.
The remote Client Access server returns MailTips information about the remote
recipients to the local Client Access server.
The Client Access server returns the MailTips information back to the client.
To limit performance impact, you should be aware of a few constraints. First, only
messages with less than 200 recipients will be evaluated for MailTips. Second, individuals in
a distribution group are not separately evaluated. Finally, the MailTips for Automatic Replies
and Mailbox Full are reevaluated every two hours for draft messages that are left open for
extended periods when being composed. This ensures a user has fresh information when they
leave a message open for a long period of time.
Planning Client Access to Exchange
When planning Client Access Server architectures, you need to consider several
points. Figure 4-14 shows the components—the physical architecture, the certificates
and namespaces, and site resiliency requirements—that define a design.
• How many servers
and locations
• Internet
Site Resiliency and
Load Balancing
• Failover site or
Multiple Active sites
• What is the unit of
Certificates &
End State Architecture
• Which services
need to be secured
• How will users
access services
FIGURE 4-14 Client Access Server planning
What is namespace planning? As you will see, the term namespace can be applied to
many different things. Recall that Chapter 3, “Exchange Environmental Considerations,” had
Client Access in Exchange 2010
some discussions on namespace planning for Active Directory and Client Access. The options
discussed were consolidated datacenter, single namespace with proxy site, single namespace
with multiple sites, regional, and multiple forests. Namespaces can apply to other objects,
such as Active Directory site design, certificate planning, or how users access their mailboxes
(OWA, OA, POP3, and so on).
Namespace in general refers to any name you assign to your servers, a group of servers,
a site, an Internet POP, and more. It refers to the names you configure as internal URL and
external URL to allow users to find the servers that they need to connect to when they want
to for download the OAB, retrieving Free and Busy information, and changing UM settings
for a mailbox in your organization. It also includes properties such as the common name on a
certificate and any additional subject alternative names set for those certificates as you begin
to publish your Client Access services both inside and outside your network.
The Client Access Server, unlike other roles (such as Transport), needs to be configured
with suitable certificates, load-balanced URLs, and other settings before it will work correctly
for all but the simplest environments. Because each design may differ in requirements and
complexity, no one design fits every situation.
You have to plan your namespace usage if any of the following are true:
You are not able to take advantage of split DNS, which prevents you from using the
same names to gain access to your servers on the inside and from the outside.
You want to introduce load balancing and fault tolerance by having multiple Client
Access servers in one site.
You have multiple Active Directory sites and you need to make sure your clients
retrieve information from the correct site.
You have different clients accessing Exchange.
Client Access Services and Physical Architecture
Understanding Client Access planning starts with an understanding of each service and how
clients access their mailbox data given different physical topologies.
AutoDiscover plays an important role in creating users’ mail profiles and providing the client
URLs for features such as free/busy, Unified Messaging, and the OAB. Because AutoDiscover
information is refreshed when the client starts and at regular intervals (every 60 minutes),
it provides a mechanism to move a mailbox around and not have to manually reconfigure
every mail client. This interval can be changed with the Set-OutlookProvider by setting the
TTL parameter to the number of hours for the interval. However, Windows Mobile devices can
use AutoDiscover for its initial profile creation, but it does not reconfigure the client once the
profile has been created.
The client finds the URL for AutoDiscover differently based on whether the client has
internal access or external access.
Planning Client Access to Exchange
Internal clients are clients that are domain joined and can successfully query an Active
Directory server for AutoDiscover information. Figure 4-15 shows the process internal clients
use for AutoDiscover.
FIGURE 4-15 Internal AutoDiscover process
Clients search Active Directory for a service connection point object (SCP).
Active Directory returns a SCP that includes the location of the client’s nearest
AutoDiscover service.
The client securely (HTTPS) requests AutoDiscover information.
The Client Access server returns the best available service URLs for the client request.
An SCP object is created in Active Directory during the Client Access server’s installation
with an AutoDiscoverServiceInternalURI value equal to that of the FQDN of the server itself.
The AutodiscoverSiteScope property is also configured with the Active Directory site that the
host was in when the Client Access Server role was installed. This property defines the Active
Directory sites that the Client Access server provides coverage for. These properties are never
changed automatically, even if the host moves to a different Active Directory site. It is critical
to change this property if your standard build process is to install servers and move them to
a new Active Directory site when servers are placed into production. As you will see in the
example in Figure 4-16, failure to correct the AutodiscoverSiteScope property will result in
a Client Access server never being used, potentially being overburdened, or a non-optimal
server being selected.
Another key concept to understand is that the client attempts to connect to the
Client Access server closest to the client computer making the request, but the URLs and
configuration the server returns to the client are for a Client Access server in an Active
Directory site closest to the user’s mailbox.
Few organizations will have large numbers of Active Directory sites, but in the event your
organization does, you will meet the upper limit of the AutoDiscoverSiteScope property
of the SCP object, which can store about 800 entries. If you try to go over this limit your
set-ClientAccessServer cmdlet will return an ADMIN_LIMIT_EXCEEDED error. One possible
Client Access in Exchange 2010
workaround is if you have an Active Directory site with more than one Client Access server,
you can split up the list among them. For example, assign 400 to one Client Access server
and 400 to the other. This only works if you also change the AutoDiscoverServiceInternalURI
parameter to reference a load-balanced name that includes all Client Access servers within
an Active Directory site. This is discussed further when we discuss load balancing later in the
If you have a large number of sites that do not have Exchange servers, check out
Brad Hugh’s blog for a script that automates site assignment:
Figure 4-16 has three Active Directory sites, with Client Access servers and Mailbox
servers are located in sites A and B. Outlook 2007 clients are located in all sites. By default,
the AutoDiscoverSiteScope for the Client Access servers in site A is set to site A. The
AutoDiscoverSiteScope for the Client Access servers in site B is set to site B. The client
computers in site A will only AutoDiscover to Client Access servers in site A. The client
computers in Site B will only AutoDiscover to Client Access servers in site B. Clients in Site C
will AutoDiscover to Client Access servers in either site A or site B because none of the Client
Access servers is specifically configured to cover site C. This could mean a client in one
country could AutoDiscover to a Client Access server overseas, possibly resulting in a poor
user experience. To correct this issue, set the AutoDiscoverSiteScope on the Client Access
servers in site B to cover sites B and C. Clients in those sites will only use the Client Access
servers in Site B for AutoDiscover. This is the optimal setup for this topology.
Site A
Site B
Site C
FIGURE 4-16 AutoDiscoverSiteScope example
Remember that the configuration information the Client Access server returns is for the
Client Access server closest to the user’s mailbox, regardless of the location of the client
computer. All subsequent AutoDiscover requests still go to the Client Access server closest to
the client computer—not the Client Access server closest to the mailbox.
Planning Client Access to Exchange
To achieve this configuration you would add the AD site names by running a command
such as the following:
Set-ClientAccessServer –Identity SiteACAS –AutoDiscoverSiteScope “Site A”, “Site C”
Another problem will arise with the default configuration. If the site contains multiple
Client Access servers, Outlook does not automatically load-balance its connections among
the available hosts. Remember that Outlook receives a list of SCP records from Active
Directory and will attempt to connect in the order it was received. When Active Directory
generates the list, it orders the hosts by creation date of the SCP record (created during the
Client Access server installation). The combination of these two operations means the one
Client Access server (the oldest Client Access server) will handle all of the AutoDiscover traffic
in that site. Additionally, the service URLs returned by the Client Access server are not equally
load-balanced either. They are randomly chosen from all the Client Access servers within the
mailbox server site.
The solution is to change the SCP record to provide a load balanced URL for AutoDiscover.
To enable this, use the set-ClientAccessServer cmdlet with the AutoDiscoverServiceInternalUri
property. Of course, this means you will need a load-balancing mechanism, such as Windows
Network Load Balancing (NLB), round robin DNS, or a hardware load balancer.
This load-balanced name is another example of a namespace that you need to consider
and plan for. In this case it is a namespace that is common for all of the Client Access server
within a single Active Directory site.
Service Connection Points and AutoDiscover
Greg Taylor
Senior PM, Exchange Product Team, Microsoft Corporation
he way Outlook uses SCP records to find the closest AutoDiscover Service
becomes even more of an exercise in namespace planning if you choose to
install Exchange Server 2010 into an existing Active Directory site that already
contains Exchange Server 2007 servers.
It becomes a challenge when a user’s mailbox is on an Exchange 2010 mailbox
server because this means a 2010 Client Access server must be used to service the
user’s AutoDiscover request. Exchange 2007 SP2 introduced some code to redirect
any requests for 2010 users to a 2010 Client Access server, which is great, but once
you understand the logic, as explained in this chapter, it raises some questions.
Remember, in any SCP lookup the client gets back a list of Client Access servers to
query: either all those in-site, meaning the SiteScope attribute matches the AD site
of the client computer, or all other Client Access servers out-of-site, meaning all the
others. The client then attempts to connect the Client Access server at the top of
that list, which will always be the oldest.
Client Access in Exchange 2010
In a mixed 2007/2010 Active Directory site, the oldest Client Access server will
almost always be a 2007 Client Access server (unless your deployment went down
a very interesting or bizarre route). So the oldest 2007 Client Access server will get
all the AutoDiscover requests, and will redirect those meant for 2010 Client Access
server to a 2010 Client Access server.
But what if you have changed all the AutoDiscoverServiceInternalURI properties in
the SCP objects to load-balanced names (as you should) to avoid making one Client
Access server a single point of failure? Now you need two internal namespaces in
that site, so a 2007 Client Access server can redirect to a 2010 Client Access server. If
you set the value of AutoDiscoverServiceInternalURI on all Client Access servers in the
site to be the same value, how could one Client Access server redirect to another? It
can’t. So, in a mixed-version site, plan for two internal (and two external) namespaces
to be sure you can provide clients with redirection and URLs that point to the correct
version of Exchange—that is, the one matching the mailbox version of the user.
If the client is external or non-domain joined, there is a different process for AutoDiscover, as
shown in Figure 4-17.
Internal Network
FIGURE 4-17 External AutoDiscover process
The client attempts to search Active Directory and fails.
The client attempts to connect to the AutoDiscover service using a well-known URL
made with the user’s primary SMTP address (just the domain parts after the @). These
well-known URLs include the following:
Planning Client Access to Exchange
A local XML file if one has been configured; if found, this overrides any other
SRV record (only applies to Outlook 2007 clients with Service Pack 2 or later)
The Client Access server processes the request and returns the best available service
URLs for the user.
Another possible option for AutoDiscover is to deploy a static XML file to the client. This is
particularly useful when you have two forests using the same SMTP address. This may happen
during a company acquisition when the acquired company starts using the parent company’s
domain. Outlook 2007 or later clients may look to the wrong Exchange organization in this
case. A registry entry can also force the static XML to be preferred over any other method.
To enforce the XML check first set the following registry keys:
Office 2007 – HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Autodiscover\
Office 2010 – HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Autodiscover\
Value: 1
To set the path to the local XML file, set the following:
Office 2007 – HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Autodiscover\
[Domain Name]
Office 2010 – HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Autodiscover\
[Domain Name]
Value: Full Path to XML file
For example,, and its value is the full path to the XML file,
C:\Program Files\Microsoft\Office12\Outlook\AutoDiscover\
Of course, you will need a way to deploy this XML file to all of your client computers.
An example XML file, and the schema for the is explained in the Technet article found at You can use products such as
System Center Configuration Manager or Active Directory Group Policies to push it out.
Client Access in Exchange 2010
A new option was introduced in an Outlook 2007 hotfix (and is included in Service Pack 1 and
later). This added an additional check for a DNS SRV record. This option is extremely useful
for Exchange organizations that have a large number of SMTP domains, or frequently change
the SMTP domains. Let’s use Litware as an example. Litware may have 100 additional SMTP
domains. Some are “vanity” addresses that groups within Litware use, and the addresses have
brand recognition, so retiring the addresses is not an option. For this example, we will use as one of these vanity domains. One option is to purchase a SAN certificate
with each SMTP domain name and point all of the DNS
records at the one location; however, this can become expensive and is difficult to maintain.
By using an SRV record, AutoDiscover will find the domain and the SRV
record pointing at a host (, for example) that is providing the AutoDiscover
service and then redirect the client to the address. The end user will get
a message asking permission for the user to allow the redirection, as shown in Figure 4-18.
FIGURE 4-18 AutoDiscover Redirect dialog box
The user can then select the check box Don’t Ask Me About This Website Again and thus
will not see the prompt again. Another option is to set a registry key so that the user will
never see the dialog box. The registry key is described in KB article 956528 (http://support You create a new string value with a delimited list of HTTPS
servers to which AutoDiscover can be redirected without prompting for confirmation from
the user. You can then use any distribution method to push out the registry change.
With either method, the connection to the Client Access server is secured using SSL and
certificates. For a secure connection to succeed, the certificate must be valid by having
a trusted root (and chain) and a name that matches the URL the client connects to, and the
certificate cannot be expired. For Outlook 2007 domain-joined clients, Outlook will ignore the
requirement for trusting the root certificate, allowing the out-of-box self-signed certificate
to work. It is a good idea under all circumstances to replace the self-signed certificate with
a valid commercial or internal PKI-generated certificate.
Planning Client Access to Exchange
Outlook 2010 reverses this behavior and will display a warning to the user if there
is a self-signed certificate—even for domain-joined clients. This again reinforces the best
practice to always replace the self-signed certificate for all installations.
You can change the order—or even exclude specific steps—of the AutoDiscover process.
To change the settings add one or more of the following registry keys described in Table 4-7:
Office 2007 – HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\
Office 2010 – HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\
Key: AutoDiscover
Value: 0 (default; use typical AutoDiscover process) or 1 (enable XML file lookup)
TABLE 4-7 AutoDiscover Order Registry Settings
Forces Outlook to use the local Autodicover.xml file
before any other lookups.
Excludes lookups for a redirect from HTTP against the
SMTP domain.
Excludes lookups for Autodiscover.[SMTP domain]
[SMTP Domain]/Autodiscover/Autodiscover.xml
Excludes the Active Directory query for the Service
Connection Point (SCP) object.
Excludes the DNS SRV record check.
Outlook Web App and Exchange Control Panel
Exchange Control Panel follows the same architecture as OWA. The guiding principle with
OWA is to use a Client Access server closest to the user’s mailbox, not the Client Access
server closest to where the user is. This is because the communication between the Client
Access server and the Mailbox server uses RPC communication, which needs low latency
Client Access in Exchange 2010
and high bandwidth. Exchange achieves this via two mechanisms: redirection and proxying.
Understanding these concepts will help you later in the chapter when we look at the access
Proxying is used to access Client Access servers that are not externally available.
Figure 4-19 shows two of Fabrikam’s datacenters. Because only the Denver datacenter has
Internet connectivity, users with mailboxes in the Miami datacenter do not have a direct
way to access their Client Access server. In this scenario, the user points the Web browser to
his OWA URL, and the Denver Client Access server proxies the request using HTTPS to the
Client Access server in the Miami datacenter. The Denver Client Access server uses the Miami
Client Access server’s certificate to encrypt the conversation. It does not use the certificate
for authentication, so the Miami host can continue to use the default self-signed certificate
without problems. It is also worth noting that for one Client Access server to proxy to another,
the authentication used on the /OWA or /ECP Virtual Directory must be changed from the
default of Forms Based Authentication to Windows Integrated Authentication.
Denver Datacenter
Miami Datacenter
Mailbox Client Access Directory
FIGURE 4-19 OWA proxying
If both datacenters have an Internet connection, as shown in Figure 4-20, the client
can make a more optimal connection. For redirection to work, the external URL must be
configured with an externally resolvable address.
Planning Client Access to Exchange
Redirects to
Denver Datacenter
Miami Datacenter
Mailbox Client Access Directory
FIGURE 4-20 OWA redirection
For example, if a user whose mailbox is in the Miami datacenter opens her browser to
connect to OWA for a mailbox in Denver, Exchange will redirect the client to the appropriate
Client Access server with a message similar to that shown in Figure 4-21.
FIGURE 4-21 OWA redirect message
Client Access in Exchange 2010
Redirecting OWA URLs in Exchange 2010
Brian Desmond
Microsoft MVP, Directory Services, Brian Desmond Consulting, North America
ne of the things I’ve been doing for as long as I can remember is redirecting
requests that don’t go to (or /exchange) to the
correct URL. So, if someone goes to or,
he gets redirected to the correct (secure) URL. Historically I’ve always done this with
two components:
A custom Web site listening on Port 80 on each Client Access server
A default.aspx file in the root of the Default Web Site redirecting to /owa
This approach no longer works with Exchange 2010 Client Access server because
the PowerShell virtual directory actually operates over Port 80 (authentication is
Kerberized). If you try to tinker with this, you’ll start getting errors like the following
from Remote Windows PowerShell:
. . . The WinRM service cannot process the request because the request needs to be
sent to a different machine. Use the redirect information to send the request to
a new machine. Redirect location reported:
PowerShell. . . .
To work around this, you need to use the HTTP Redirection feature in IIS (the
default.aspx trick mentioned in the second bullet in the preceding list should
work, too), and also remove the requirement for SSL at the top-level Default Web
Site object. You have to be careful when you do this because when you configure
settings on the Web site, IIS will push them down to any virtual directory below
which does not explicitly set that setting itself. To set up the redirect, select Default
Web Site in IIS Manager, and open the HTTP Redirect option under IIS. Complete it
as shown in Figure 4-22.
FIGURE 4-22 HTTP Redirect
Planning Client Access to Exchange
It’s very important that you select the check boxes as shown in
the figure!
After this step is complete, you need to remove the enforced redirect from each
of the virtual directories under the Default Web Site. To do this, select each virtual
directory individually, and then open the HTTP Redirect property and clear the
Redirect Requests To This Destination check box. You’ll need to do this on the
following virtual directories:
Windows PowerShell
If at this point if you simply browse to, you’ll get an
HTTP 403.4 error. This is because SSL is required at the top-level Web site. To get
the redirect working, you need to disable SSL for the top-level Web site while
leaving it enabled for the relevant child virtual directories.
Select Default Web Site, open the SSL Settings properties, and clear the Require
SSL check boxes. Like the redirection settings, this change will be inherited down
the tree for any virtual directory that does not explicitly configure the setting
independently. Ensure that SSL is required for the following virtual directories:
Windows PowerShell
If you require SSL for the Windows PowerShell virtual directory,
you will render Remote PowerShell inoperable!
After you’ve configured the redirection and SSL settings, open a command prompt
and run iisreset. At this point you should be able to browse to http://localhost
on the Client Access server and get redirected to
These steps were tested on Windows Server 2008 R2. They should be similar under
Windows Server 2008, but they may not be identical.
Exchange ActiveSync (EAS)
Exchange ActiveSync enables mailbox access for compatible mobile devices. Its access
methods are very similar to OWA. EAS proxying is shown in Figure 4-23.
Client Access in Exchange 2010
HTTPS via internalURL
Denver Datacenter
Miami Datacenter
Mailbox Client Access Directory
FIGURE 4-23 EAS proxying
If the client accesses the Client Access server in Denver, it will look up where the user’s
mailbox resides, which in this example is in Miami. It checks that the remote Client Access
server has no externalURL property set and the /Microsoft-Server-ActiveSync Virtual
Directory is configured for Windows Integrated authentication. If it passes these checks,
the connection is proxied to the remote server’s internalURL specified on the ActiveSync
Virtual Directory. If the Authentication is incorrectly set or the internalURL is not reachable,
the request fails.
EAS redirection logic is similar to that of OWA. Only Windows Mobile phones 6.1 and later
have the functionality we are about to examine. Older Windows Mobile phones or phones
that license ActiveSync technology may not behave the same way. As shown in Figure 4-24,
when a client goes to the Client Access server in Denver, it will look up where the user’s
mailbox resides and determine whether the remote server’s externalURL property is set. If it is,
the Client Access server returns an HTTP error code 451, which is a client redirect containing
the URL for the optimal Client Access server.
It is recommended that Exchange Active Sync be load-balanced for internal- and
external-facing sites. The synchronization state is stored in the user’s mailbox. If the Client
Access servers are not load-balanced, the sync will be tied to a specific Client Access server.
If that host becomes unavailable, synchronization will fail until the service is restored.
Planning Client Access to Exchange
Redirects via HTTP 451
Denver Datacenter
Miami Datacenter
Mailbox Client Access Directory
FIGURE 4-24 EAS redirection
Greg Taylor
Senior PM – Exchange Product Group, Microsoft Corporation
uite often I am asked by customers if setting the externalURL property is
required, and like all good ex-consultants, I answer, “It depends.” That’s
because all clients work in different ways, so the question I respond with is “What
client are we talking about?”
This is the ActiveSync section of the book, but let’s talk about OWA first: if you don’t
set an externalURL on a VDir, does that mean you cannot connect? No, it doesn’t—you
can connect just fine as long as the client can resolve the name to an IP, the certificate
is valid, and the right authentication is enabled. What if you have two Active Directory
connected sites? If you don’t set an externalURL, how can you redirect a client to
the other site? You can’t—so having externalURL configured for OWA is not strictly
necessary unless you need redirection. Still, I would always recommending setting
them, and setting them all to the same value within an Active Directory site.
Client Access in Exchange 2010
Now, back to ActiveSync. This is where things get more interesting in a nerdy kind
of way. When an ActiveSync client performs an AutoDiscover request, the Client
Access server returns to the client the server configuration it should use. And
that setting is (drum roll please) the value of externalURL on the Internet-facing
Client Access server. What if, like OWA, you didn’t set it during install, or since? No
AutoDiscover. So if you want AutoDiscover to work, you need to set it on all the
Client Access servers in the Internet-facing Active Directory site(s).
Exchange Web Services
Exchange Web Services (EWS) is different than the other services discussed so far because
it only supports proxying. It relies on AutoDiscover to provide clients, whether Outlook or
an application, with the correct URLs. Figure 4-25 depicts the proxy scenario for EWS.
HTTPS via internalBypassURL
Denver Datacenter
Miami Datacenter
Mailbox Client Access Directory
FIGURE 4-25 EWS proxy
EWS calls are generally stateless, but a number of operations require EWS to maintain state.
For example, subscriptions require affinity (reconnecting to the same host) to work. However,
the Availability Service is an example of an Exchange Web Services that is stateless. Even with
the Exchange Web Services that are stateless, maintaining state has performance benefits.
A problem arises when Denver has to proxy to Miami. As you can see in Figure 4-25, when
Denver has to proxy to Miami, Miami’s Client Access servers are behind a load balancer (and
Planning Client Access to Exchange
the internalURL would appropriately be set to the array). For affinity to be maintained, the
proxy process uses the internalNLBBypassURL. The internalNLBBypassURL is set by default to
the FQDN of the host. This value should never be changed.
Also note that in Service Pack 1, EWS now supports certificate authentication. This
addition can enforce extra security from clients and provide more control over who and what
applications can access EWS.
RPC Client Access
The introduction of the RPC Client Access layer means that Outlook clients now connect to
the Client Access server to access a user’s mailbox. It is a requirement to have at least one
Client Access server per Active Directory site where a Mailbox server has been installed.
AutoDiscover uses the RPCClientAccessServer setting on the mail database to configure
a client to use the Client Access server in the Mailbox server’s site. The RPCClientAccessServer
property is automatically set to a randomly selected FQDN of a Client Access server in the
same site as the database if an array has not already been created. If it has already been
created, it will be set to that instead. Note that this setting is not updated in the event of
changes, such as removing the Client Access server array or installing additional Client
Access servers.
There is not a concept of proxy or redirection for RPC access in Exchange 2010 RTM.
Client Access servers will make a direct connection to a Mailbox server across sites. The
only way to prevent this is to change the RPCClientAccessServer setting on the database.
In Service Pack 1, redirection logic and the ability to disable cross-site direct connections
were added for RPC Client Access. Redirection is controlled by three properties (in addition
to enabling redirection)—the Home Server property on the user’s directory object, the
preferred database site (such as the RPCClientAccessServer property), and the Active database
site. Disabling cross-site connections forces redirection behavior and the Outlook client will
reconnect to the Client Access server array in the other site.
The default setting for RPC Client Access is that encryption is required. By default, older
Outlook clients such as Outlook 2003 do not enable encryption. You have two options
when using such clients: either enable encryption on the client or remove the encryption
requirement on the Client Access server. It is recommended that security be preserved
and the Outlook clients have their settings changed. This, however, may be difficult to do
in organizations that do not have automated processes in place.
To provide for load balancing of the RPC Client Access, Exchange uses the
ClientAccessArray concept. As explained earlier, the RPCClientAccessServer setting controls
where RPC clients go for service. To allow for load balancing, this property is set to
ClientAccessArray instead of a single host. When an administrator creates the array, it does
not create any form of load balancing itself; it really is just a logical object representing
an array of servers that must be separately configured to perform load balancing. This can
be done using either hardware- or software-based load balancing. Only one array is allowed
per Active Directory site, and multiple DAGs can utilize the same Client Access server array.
Client Access in Exchange 2010
One option frequently recommended when load balancing RPC services is to restrict the
ports required. Without restrictions in place, a large range of ports need to be configured,
which can overwhelm some load-balancing devices. The static port for RPC Client Access is
configured in the registry using the following key. The key needs to be set on every Client
Access server to the value of the port used for TCP connections,
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\
Value: TCP/IP Port
It is recommended that you set this value to a high port that is not used by any other
application, such as 50,000.
This setting does not affect Outlook Anywhere connections because those are hard-coded
to use port 6001.
Additionally, the static ports for the two RPC endpoints for the Exchange Address Book
Service are set in the Microsoft.Exchange.AddressBook.Service.Exe.config file. This file is
located in the bin directory of the Exchange installation path. The RpcTcpPort value should be
set to the TCP port to be used for connections. Again, setting this to a port not used by any
other application is recommended, such as 50,001.
Do not change the values for NspiHttpPort and RfrHttpPort—changes may result in
delays in Outlook Anywhere connecting to Exchange.
After these two changes are made, and the Microsoft Exchange RPC Client Access Service
and the Microsoft Exchange Active Directory Topology Service are restarted, Outlook will still
connect to the RPC Endpoint Mapper to be told which port to use for service, but instead of
being provided with a dynamic port, as would be the default, Outlook uses the two statically
configured ports.
Client Access Server Array Names
Greg Taylor
Senior PM – Exchange Product Team, Microsoft Corporation
hen considering what names to put onto certificates and what FQDN’s
to set the various VDirs and parameters to, I am sometimes asked which
FQDN the Client Access server array should be set to and whether that name should
be on the certificates used.
Planning Client Access to Exchange
Taking those questions in reverse order (the second question is easier to answer),
Outlook connects to the array using RPC, not SSL. So no, the FQDN you use for the
array does not need to be on any certificate, unless you happen to be using the
same FQDN for other services—EWS, OAB, and so on.
So, what should you call your array? I think Greg is an excellent name—you
should call it that. If you can’t, you should name it something simple and easy to
understand but which only resolves in internal DNS. Why? Let’s say you named it and that name exists in both internal and external DNS. When
you fire up Outlook at home it will try to connect to using RPC,
and if it can resolve that name to an IP, it will keep trying and trying, until it times
out and then falls back to trying to connect over HTTPS (which likely will work, but
the delay is a killer if you are an e-mail addict like me). If, however, you had named
it, or better still, and neither of those exist
in external DNS, Outlook immediately starts trying to connect over HTTPS.
Outlook Anywhere
Outlook Anywhere enables the full Outlook client to access Exchange using HTTPS by
wrapping the RPCs that Outlook usually uses to access a Mailbox server with HTTPS to
enable passage through firewalls. The advantage is that this design gives users access to their
mailboxes over virtually any network, without special VPN solutions or additional firewall rules
that most companies already enable for Internet access.
Enabling Outlook Anywhere requires several steps, but the important part to understand
is that AutoDiscover provides the Outlook Anywhere host name and Web service externalURL
properties to configure the client to connect to Exchange. If you have more than one Internet
facing Active Directory site, it is recommended that each site have a separate external host
name. The AutoDiscover service will always provide service URLs for the Client Access server
closest to the user’s Mailbox server. In Figure 4-26, the Miami datacenter does not have
Internet connectivity. In this case, a user with a mailbox in Miami will first access the Client
Access server in Denver because it is externally accessible. The Denver Client Access server will
make an RPC connection to the RPC Client Access server in Miami, which in turn connects to
the Miami mailbox.
Because Outlook Anywhere utilizes the HTTP protocol, its connections are half-duplex. This
means two connections are created for a conversation, RPC_DATA_IN and RPC_DATA_OUT,
as shown in Figure 4-27. Each connection is tagged with a client session ID. The RPC server on
the endpoint uses this client session ID to know that data it receives via RPC_IN_DATA must
be returned using the RPC_DATA_OUT with the same client session ID.
Client Access in Exchange 2010
Denver Datacenter
Miami Datacenter
Mailbox Client Access Directory
FIGURE 4-26 Outlook Anywhere
Windows 2008
Client Access Servers
RPC and Directory
FIGURE 4-27 Outlook Anywhere data flow
Planning Client Access to Exchange
This mechanism sometimes presented a problem in Exchange Server 2007 when an SSL
ID-based load-balancing solution was placed between the Client Access server and clients.
The load balancer does not recognize that these sets of paired connections need to be sent to
the same Client Access server, so often it distributed these connections to all the Client Access
servers in the load-balancing pool. This meant connections were sometimes split between
different Client Access servers and so bidirectional connectivity was broken.
In Exchange Server 2010—or more precisely, in Exchange Server 2010 running on
Windows Server 2008—this issue is solved by a component called the Load Balancing Service
(LBS). Oddly, LBS has nothing to do with load balancing itself. What it does is detect when
sessions from the same client have been split across multiple servers configured in an array
and proxy connections between the hosts to ensure that split sessions no longer cause
A few settings for Outlook Anywhere impact certificate namespaces. Figure 4-28 shows the
Microsoft Exchange Proxy Settings dialog box.
FIGURE 4-28 Outlook Anywhere Proxy Settings in Outlook
The dialog box itself has changed slightly through different Outlook client versions.
It is generally accessed through the account settings for Exchange (in the profile) on the
Connection tab. On the Connection tab there is a section that refers to connecting to
Exchange via HTTP, and there is a button for Exchange Proxy Settings.
The first setting to understand is the URL used to connect to the proxy (Client Access
server). This is the URL location Outlook will use to connect to Exchange. The second text box
is for the certificate name in the Microsoft standard form (msstd). This is the subject name
Outlook expects to find on the certificate presented from the Client Access server when
making a connection. This name should not be a SAN because of incompatibilities in the
Client Access in Exchange 2010
operating system and with Outlook. (This became less of an issue after Windows Vista SP1
was released.) The default configuration on the Client Access server will set these to the same
value (the Outlook Anywhere ExternalHostname). For now, let’s focus on the mechanisms
Outlook Anywhere uses. In Chapter 11 we will look at the impact these properties have on
choosing a high-availability architecture for the Client Access server.
Client Access Server Sizing Tips
Andrew Ehrensing
Principal Consultant, Microsoft Consulting Services, US Central Region
hen planning for Client Access server sizing, particularly for Outlook
Anywhere, it is important to know how many connections you can expect. This
also helps capacity planning when running connections through a hardware load
balancer or intelligent firewall. To get an accurate client connection count, you cannot
rely on the hidden Outlook connection status dialog box. You can, however, use
Microsoft’s TcpView utility (
.aspx) or a network sniffer. Another good resource can be found in the
whitepaper “Outlook Anywhere Scalability with Outlook 2007, Outlook 2003,
and Exchange 2007,” available at
cc540453(EXCHG.80).aspx. Even though this whitepaper has not yet been updated for
Exchange 2010, the information it provides good guidance for planning purposes.
POP3 and IMAP4 are both client protocols used to access mailbox data. Table 4-8 highlights
some of the main differences between the protocols. Although both protocols are used to
retrieve mail, they rely on an SMTP service to send mail.
TABLE 4-8 POP3 and IMAP4 Comparison
Mail Storage
All mail is copied and used locally.
Some clients have an option to
leave a copy on the server.
Mail is stored on the server,
and can be used online or
POP3 supports syncing the Inbox
folder only
IMAP4 supports syncing all
Temporary, connected only
long enough to download mail.
Maintains connection as long
as client is running.
POP3 supports only a single
client connection to the mailbox.
IMAP4 supports multiple
clients simultaneously
connected to the mailbox.
Planning Client Access to Exchange
POP3 does not record any
message state information
such as read/unread state.
IMAP4 can keep track of
message state such as read/
unread state.
Not supported
One way to let users know their SMTP service settings is to configure the
set-ReceiveConnector cmdlet with the AdvertiseClientSettings parameter. This parameter
enables the help menu in Outlook Web App to display the SMTP server name, port number,
and authentication settings.
POP3 and IMAP4 only support proxying, as shown in Figure 4-29. Proxy configuration is
now automatic, and no additional configuration is needed to enable cross-site support.
Denver Datacenter
Miami Datacenter
Mailbox Client Access Directory
FIGURE 4-29 POP3 and IMAP4 proxy
One significant change in Exchange 2010 is in its security settings. Exchange 2010 no
longer supports NTLM authentication for POP3 or IMAP4. PlainTextAuthentication no
longer allows Secure Password Authentication (SPA) and the client must support Kerberos
authentication. It is still a best practice to leave the default setting to SecureLogin, which
requires TLS encryption and provides the best security.
Client Access in Exchange 2010
The Client Access server blocks POP3 and IMAP4 from the Anonymous and Guest
accounts. Additionally, the administrator account cannot be used either. To access the
Administrator mailbox, you must use Outlook or Outlook Web App.
A few other settings worth mentioning are used to control the number of POP3 and
IMAP4 connections. They are listed in Table 4-9.
TABLE 4-9 POP3/IMAP4 Connection Settings
2,000; 1–25,000
2,000; 1–25,000
16; 1–25,000
MaxConnectionsFromSingleIP may need to be configured to a higher number if clients
are coming through a firewall or load balancer that uses NAT. In this configuration, all of
the connections coming into the Client Access server will appear to originate from the same
IP address. Organizations with large numbers of clients utilizing POP3 or IMAP4 may need to
raise the number of MaxConnections. This setting controls the overall number of simultaneous
connections that can be made to the Client Access server. Finally, MaxConnectionsPerUser
controls the number of connections originating from a single user. In the case where you have
an application (such as third-party voicemail integration software) that makes a connection
with a service account this setting may need to be raised. As with all of these settings, there is
a trade-off between number of connections and server performance. You can’t apply a simple
formula to determine what the settings should be. It will depend on factors such as server
hardware, client software, and user profiles.
Client Access Summary
As you can see, the mixture of protocols, client versions, and other factors makes Client
Access server planning complex. Table 4-10 summarizes each access method and its ability
to redirect and proxy Client Access Server connections.
TABLE 4-10 Redirect and Proxy Summary
Outlook Web App
Yes (for Windows
Mobile 6.1 and
above or other
compatible clients)
Planning Client Access to Exchange
Exchange Web
No, except for the
EWS elements of
Outlook Anywhere
or for any application
using AutoDiscover.
Exchange Control
Outlook Anywhere
will access
remote mailbox
directly via RPC
or AutoDiscover
will provide the
correct end
points for the
client to use.
Table 4-11 summarizes each service’s internalURL and externalURL configuration settings.
The externalURL settings will depend on whether the services are in an Active Directory site
with Internet connectivity.
TABLE 4-11 Summary of Load Balanced URLs
Exchange Web
Control Panel
Use the Server FQDN if the site is the target of a proxy, otherwise use the NLB FQDN. The AutodiscoverServiceInteralURI (SCP record) should always be configured to the NLB FQDN.
Client Access in Exchange 2010
Client Access High Availability
This section will work through the complex task of designing a highly available Client Access
layer. Removing single points of failure requires that redundant Client Access servers be
available. However, after you add multiple hosts, you have two problems to solve:
How to direct traffic between hosts
How to maintain session information if required
Some Exchange applications are stateful, meaning the application needs to remember what
the client was doing previously. However, if you have multiple hosts, or when you’re using
stateless protocols such as HTTP, this state information will be lost between client calls. In the
case of multiple load-balanced hosts, affinity is a mechanism to direct calls to a host that was
chosen in the initial request.
Before we go into a deeper discussion on load-balancing solutions, it is important to
understand the different types of affinity and how they are used. The Client Access server
uses a number of protocols that will need to be load balanced, including HTTP and RPC.
Remember also that some Client Access server services require affinity and some do not.
When choosing a load-balancing solution that will meet the potentially diverse requirements,
remember that it may need to support a variety of affinity types.
This type of affinity uses cookie information transmitted during typical client/server sessions.
This type of affinity is only useful for protocols using HTTP. This would not be an option
for RPC Client communication, for example, but OWA using forms-based authentication is
an example of an application that does use existing, or application, cookies.
Using load balancer cookies are similar to the previous affinity, except that the load
balancer creates the cookie itself and does not rely on existing cookies. Again, this is only
usable with protocols using HTTP. Additionally, the client must support the addition of load
balancer– generated cookies. Exchange ActiveSync, Outlook Anywhere, and some Exchange
Web Services do not support this capability. OWA, ECP, and Remote Windows PowerShell are
very good candidates for this type of affinity.
Source IP is perhaps the most common and widely supported type of affinity. With source IP
load balancing, the load balancer maps a client’s IP address and destination host. All traffic
from that source IP will continue to go the same destination host. Source IP load balancing
has two main drawbacks.
Planning Client Access to Exchange
First, affinity breaks when clients change their IP addresses. If you have an environment
where this happens frequently, such as mobile clients roaming between wireless networks,
this will cause issues visible to users. They may experience symptoms such as having to
Second, if you have an environment where many clients share the same source IP, such as
when a device performing Network Address Translation (NAT) is used, the load will not be
evenly distributed.
SSL session ID is generated during the establishment of an SSL encrypted session. SSL
session ID has a big advantage over source IP affinity in that it can uniquely identify clients
sharing the same source IP address. Another advantage is that there is no requirement to
decrypt the SSL traffic to load balance. This is a hard requirement for using client certificate
authentication. Renegotiating the SSL session ID puts extra overhead on the server. Directing
traffic to the same server saves processing time and prevents performance impacts.
SSL session ID does not work well with all clients. Some browsers, such as Microsoft
Internet Explorer 8.0, create a new SSL session for each browser process. Every time a user
creates a new mail, a separate window pops up, creating a new SSL session. The exception to
this is when users use client certificate authentication. The same SSL session ID is used for all
communication to a specific host. Outlook Anywhere and some mobile clients, such as the
iPhone, open several Client Access Server sessions. Because each session gets a different SSL
session ID, each session could end up on a different server. As discussed earlier, this is not
a problem because the LBS component of Windows Server 2008 will correlate the
RPC_IN_DATA and RPC_OUT_DATA. However, this will cause additional overhead and can
have an impact on server performance.
Load-Balancing Solutions
To provide redundancy and not have a single point of failure requires multiple Client Access
servers in the same Active Directory site. Given this requirement, a mechanism is needed to
provide failover redundancy if a host becomes unavailable. It is also needed to effectively
distribute client traffic. Three types of traffic need to be load balanced:
Traffic from internal networks
Traffic from external (internet) networks
Traffic from other Client Access servers (proxy)
A goal is to use a single load-balancing solution that works for each of these types of
traffic to lower complexity and cost. Because you have a number of load-balancing options,
consider the following when choosing a solution:
Features Does it perform SSL offloading?
Manageability How easy is it to configure and maintain the solution?
Client Access in Exchange 2010
Failover detection Does it support advanced detection (service awareness), or
simple ping (host awareness)?
Affinity What options does it support to keep client connections returning to the
same host?
Cost How much to implement the solution?
Scale How does the solution work as the number of hosts increases?
Windows Network Load Balancing (WNLB) has been part of the Windows Server
operating system since NT 4.0. Of course, a lot has changed since its early days. WNLB
can scale to 32 hosts, but the practical limit for Exchange is 8 hosts based on Microsoft’s
internal deployment experience. One of WNLB’s advantages is that it is relatively
inexpensive to implement.
One disadvantage of WNLB is that you cannot use it combined with Windows
Clustering. If you are trying to configure an all-in-one server that has the Mailbox role
and Client Access Server role, and you are using DAGs, you must use a hardware-based
load-balancing solution for Client Access. Another drawback is that WNLB only supports
source IP affinity or no affinity. This may limit its ability to effectively load balance across all
of the Client Access protocols.
If you need to support more than eight nodes in your Active Directory site, you must
consider a hardware load balancer. Having a dedicated piece of specialized hardware allows
for the best performance and a considerable amount of features. Most hardware load
balancers support multiple affinity types, and even allow for the ability to try fallback if one
type fails. Typically, hardware load balancers support more advanced node health checks.
These range from a simple ping test to measuring response times to a custom Web page.
More expensive solutions also provide hardware redundancy, further eliminating any single
points of failure.
Probably the biggest disadvantage of a hardware load balancer is the cost of deploying
a hardware solution. For large-scale deployments, however, this is typically the solution
Intelligent firewalls, such as Microsoft Threat Management Gateway (TMG) or Forefront
Unified Access Gateway (UAG), are similar to the hardware load balancer solution, but
provide additional security features. All of these products can create additional policies to
further control the services they reverse proxy for. For example, with Active Directory groups,
you can control what time during the day groups of users can access OWA. And as you will
Planning Client Access to Exchange
see later on in the chapter, you can unify the namespace and use groups to control routing
and load-balancing decisions.
One disadvantage is that with great power comes great complexity. These solutions
require more testing and more administration and operational support than the other
solutions. One way to mitigate this is to buy an appliance. Appliances are prebuilt solutions
that generally provide additional tools for administration and are optimally configured by the
DNS round robin takes advantage of DNS’s ability to map multiple hosts to a common name.
For example, if we have three Client Access servers registered in DNS, the A record entries
would look like this:
The first request returns the IP address of The second request returns, and the third request returns The fourth request returns the first
IP address again, and the pattern would continue.
The main advantages of DNS round robin are its low cost to implement and ease of
configuration. Unfortunately, the limitations of DNS round robin limit its use to labs, or very
small implementations (such as proofs of concept). One of these limitations is no support for
affinity. It is up to the application to maintain affinity. For example, a Web browser navigating
to will actually use the IP address the DNS server returns from the name
resolution query. Internet Explorer actually caches DNS entries for 30 minutes. Because of
this caching, the Web browser could try to reach an unavailable server until its cache expires.
And what’s (possibly) worse, even if the host you are currently using stays available, after the
cache expires it is likely that the next time the name is resolved a new Client Access server will
be returned. This will result in a loss of all state information and the session is lost.
DNS round robin also does not have any health checks or dead node removal. In the
preceding example, if becomes unavailable, DNS round robin will happily
continue to return the down host’s IP address every third request.
Finally, changes to DNS can take time to propagate. If a new Client Access server is added
to DNS, it will be underutilized until the record propagates fully.
As you can see, you have a variety of solutions to choose from, depending on the business
requirements and budget. Figure 4-30 offers a handy chart comparing affinity, load
balancing, and other considerations for choosing a load-balancing solution.
Client Access in Exchange 2010
Hardware NLB
(F5, Cisco, Citrix)
All Types
+ Automatic Failover
+ Combines with
– Cost
Windows Clustering
+ Best Performance
Intelligent Firewall
Source IP
+ SSL Bridging
+ Enhanced Security
+ AD Integration
– Complex
Software Network
Load Balancing
Source IP
+ Included in OS
+ Easy to Deploy
– Limited Scale
– Cannot use
with Windows
DNS Round Robin
Random IP + Simple to Configure
– Manual Failover
– Long Caching
FIGURE 4-30 Load-balancer summary comparison
Certificates for Client Access Services
Out of the box, Exchange 2010 provides self-signed the certificates to ensure without any
configuration changes that basic security is in place. For most organizations, this is not good
enough, for a few reasons. First, because the Exchange server itself signs the certificate, most
internal clients and all servers outside the Exchange organization will not trust it. Second,
the self-signed certificates use the host name as the subject name. Very few companies want
users, for example, to access Exchange services such as OWA with a Client Access server’s host
name (as opposed to a friendly URL such as webmail). Finally, in a fault-tolerant design it may
be impossible to load self-signed certificates onto a hardware load balancer.
Recall the discussion of certificate basics in the last chapter. If your company has an internal PKI,
that is one option for replacing the self-signed certificates. However, it may be challenging to
deploy the internal certificate to mobile devices or non-corporate managed assets. Another
option is to buy a third-party certificate. If you are purchasing a certificate, consider the following:
Ensure that the certificate authority (CA) root is trusted by all of the clients in your
organization (operating system, browser, smartphones, and so on).
Use a CA that is a Unified Communication Certificate Partner for Exchange
and OCS. (Refer to for more information on
UC certificates.)
The certificate vendor sells the type of certificate you require (SAN, Wildcard).
The certificate vendor has a flexible pricing model that allows you to add or change
names at any time or load the certificate on multiple hosts without penalty.
Planning Client Access to Exchange
The next few figures show the Certificate Wizard in action. The wizard is located in the Action
pane when the Server configuration node is selected in the console tree and the Client Access
server is selected in the result pane.
The first step is to pick a friendly name for the certificate. This name has no effect on any
URLs or configuration later on; it is simply used as an easy way to identify the certificate in
the Exchange Management Console. The second step is to request a wildcard certificate. In
Figure 4-31, this setting is not enabled and the certificate will use SANs instead.
FIGURE 4-31 Certificate Wizard Steps 1 and 2
Figure 4-32 shows Steps 3 and 4. In Step 3, the administrator selects which services the
Client Access server will enable and picks the URLs that users will use to access that service. For
this example, OWA is enabled internally and externally at Step 4 shows
a summary of the names that will be requested for the certificate. On this step you can make
modifications, such as adding the Client Access server host names if required. One name will
need to be set as the certificate’s common name; the selected name is shown in bold. Later in
this chapter we’ll discuss how this setting in particular impacts Outlook Anywhere.
FIGURE 4-32 Certificate Wizard Steps 3 and 4
Client Access in Exchange 2010
The last two steps are shown in Figure 4-33. In Step 5, the administrator inputs the
metadata for the certificate request. This includes information such as state, city, and
organization. Finally, Step 6 is the last review before the administrator clicks the New button
to generate the certificate request.
FIGURE 4-33 Certificate Wizard Steps 5 and 6
If the cmdlet is successful, the management console gives the cmdlet syntax that was used
by the wizard. For this example, the cmdlet was:
New-ExchangeCertificate –FriendlyName 'CASCert' –GenerateRequest –PrivateKeyExportable
$true –Keysize '2048' –SubjectName 'C=US,S="CO",L="Denver",O="litwareinc",OU="IT",CN=' –DomainName '',''
–Server CAS01
At this point the administrator can submit the output file to the certificate authority.
The Certificate Wizard greatly simplifies the request process.
Use as few numbers of certificates as possible. You can secure each Exchange service with
a unique certificate, but that will be harder to manage and possibly cost more money in
the end. Namespaces are the reason you may need multiple certificates. For example, in
companies using POP3 or IMAP4, the friendly URL could be, whereas
POP could be Instead of these separate names, they could both share
Internet Information Server (IIS)
Many of the Exchange services are exposed through Internet Information Server (IIS) in
Windows. By default, they share the same certificate because they are all in the default Web
application pool. These services include:
Outlook Web App
Exchange Control Panel
Exchange Web Services
Planning Client Access to Exchange
Exchange ActiveSync
Outlook Anywhere
Offline Address Book
In general, most deployments can get away with just using two namespaces: one for all
of the IIS services and one for AutoDiscover. As documented, there is no requirement for
the host FQDN as a subject alternate name, with a few exceptions. First is the ECP. Earlier
in this chapter you saw that Client Access servers that are the target of a proxy site should
be configured with the host name instead of the NLB FQDN. This is because Outlook 2010
integrates with ECP for some of its functionality. Outlook, unlike Client Access server-to-Client
Access server proxy, will not ignore mismatched certificate settings and will signal an error if
the host name is not on the certificate. Another scenario in which the host FQDN is required
is when users are accessing services with short names. For example, users may just type
https://mail into their Web browsers to access OWA.
As mentioned earlier, these services can have separate namespaces or share a common
one with the IIS services. It is recommended that you limit the number of certificates and
certificate namespaces wherever possible.
Live Federation
The certificate used for Live Federation can have any name on it. During the configuration
of this service you must select the certificate to be used. This certificate must be issued by
a third-party certificate authority that is trusted by Windows Live.
Client Access Server to Client Access Server Proxy
In more complex multi-site scenarios, sometimes Client Access servers do not have Internet
connectivity. For users to reach their mailbox stores, the Internet-facing Client Access server
must proxy the requests to the internal-only host. All communication between Client Access
servers is secured with SSL over HTTP. Remember that the goal is to always have the Client
Access server closest to the mailbox process requests. Client Access servers use specific host
names when making proxy requests. In spite of this, the FQDNs are not required because in
this case, the Client Access server ignores most of the certificate information. The certificate is
used strictly for encryption and not authentication. If your organization requires a higher level
of security for these internal requests, set the following registry key:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA\
Value: 0
Office Communication Server (OCS) Integration
The OCS R2 server needs to communicate securely with the Client Access server for the
instant messaging integration to work. The OCS R2 server needs to be configured to allow
access to the subject name listed on the certificate.
Client Access in Exchange 2010
Pulling It All Together
Now that the architecture, load balancing, affinity, and features have all been explained,
the next section pulls all of the information together and case studies for illustration.
Contoso Case Study
The first case study from Chapter 2, ”Exchange Deployment Projects,” is Contoso, shown in
Figure 4-34. Because a single Client Access server is relatively straightforward design, assume
for this chapter that Contoso wants to make minimal investments to increase their availability
when deploying Exchange 2010. Contoso’s end state will include two Client Access servers in
the Seattle datacenter.
FIGURE 4-34 Contoso logical architecture
Contoso proposes using Windows Network Load Balancing (WNLB) to provide high
availability for their Client Access Server role. They have to weigh the cost of servers against
the cost of purchasing a hardware load balancer. A hardware load balancer would be required
if Contoso chose to combine all roles on the two servers using a DAG as well. Contoso selects
WNLB because they have strong Windows Server administration skills and they do not want
to introduce new technology in their datacenter, as shown in Figure 4-35.
An administrator will configure WNLB with a FQDN of The administrator
then needs to create a DNS A record entry for and,
both pointing to the virtual IP address (VIP) of the WNLB array. The administrator creates an
RPC Client Access array object named and ensures that the each mailbox
database has the RpcClientAccessServer property set to that value for the Outlook clients.
Planning Client Access to Exchange
Outlook 2003/2007 Configured:
RPC Proxy End Point:
Certificate Prinicipal Name:
SAN Names:
Outlook Anywhere Hostname:
Web Service URLs
FIGURE 4-35 Proposed Contoso architecture
The service’s internal and external URLs need to be updated with the load-balanced FQDN,
including the AutoDiscoverServiceInternalURI. Because there are no proxy sites, all services
should use the load-balanced FQDN. The ExternalHostname for Outlook Anywhere should be
configured to match the certificate principal name
Fabrikam Case Study
The next scenario is more complex. Fabrikam, from Chapter 2, is our base architecture.
As shown in Figure 4-36, Fabrikam has two datacenters, one in Denver and one in Miami.
Client Access in Exchange 2010
FIGURE 4-36 Fabrikam logical view
Similar to Contoso, Fabrikam has for this case study fully deployed Exchange 2010. In each
datacenter, Fabrikam has deployed two load-balanced Client Access servers, and the Mailbox
servers are configured in a DAG. The network between the datacenters is fast enough to host
all users in both everyday operations as well as in the event of a failover.
In addition to the client version, types, and access methods, a number of factors that can
impact your design, including the following:
Are both datacenters considered active, or is one datacenter reserved for site
resiliency only?
How do external clients reach the Client Access servers (intelligent firewall, load
balancer, other)?
Is there split DNS?
Will you need to support partial failovers?
Most often in a scenario such as Fabrikam’s, the best practice is to use a separate
namespace for each Active Directory site. So Fabrikam users in Denver would access OWA
through, whereas users in Miami would use https://mail What happens when users move from one datacenter to the other?
They need to use a different URL, which could be very confusing. Because Fabrikam treats the
two datacenters as one, they want a design that has a common namespace: https://mail
Using the same physical datacenter design, you have five different ways to design high
Using wildcard certificates
Deploying the same configuration across sites
Using SAN Certificate and manipulating the MSSTD values provided to the client
Planning Client Access to Exchange
Using hardware load balancers
Deploying intelligent firewalls
A wildcard certificate is used to secure a namespace and all of its subdomains. For example,
Fabrikam buys a wildcard certificate for *, smtp.fabrikam.
com, and are all secured by the single wildcard certificate, as
shown in Figure 4-37.
r Users
Outlook 2003/2007 Configured:
RPC Proxy End Point: (Denver Mailboxes) (Miami Mailboxes)
Certificate Priniciple Name:
Outlook Anywhere Hostname:
Web Service URLs
Certificate Priniciple Name:
Outlook Anywhere Hostname:
Web Service URLs
FIGURE 4-37 Fabrikam wildcard example
In this scenario the wildcard certificate allows Fabrikam to use a single namespace. The
design will change slightly on Fabrikam’s requirement to either try to use both datacenters
actively, or treat Miami as a failover site. If Miami is only a failover site, it will be used only
when all service is lost in Denver. In this case, the external DNS record for AutoDiscover needs
to be updated to resolve to a Client Access server in Miami.
Users accessing OWA with will resolve via external DNS to a Client
Access server in Denver. If externalURL is configured on the Client Access servers in Miami,
users with mailboxes in Miami will be redirected. The other option is to leave externalURL
Client Access in Exchange 2010
blank and proxy all requests, but this assumes that the correct authentication type, Windows
Integrated, is enabled in each location.
Users in Miami will have their Outlook Anywhere connections set to failover.fabrikam.
com, but there will be no certificate warning because we changed the global setting for
certprincipalname to * with the following Windows PowerShell cmdlet:
Set-outlookprovider EXPR –certprincipalname msstd:*
Note that during a move mailbox for user from Denver to Miami, the Outlook Anywhere
connection may use a Client Access server in Denver and cross-site access the mailbox in
Miami (and vice versa for moves in the opposite direction).
In this design we use the same configuration in both Denver and Miami. By doing this, we
can only use this design for using Miami as a failover site. As you can see from the illustration
in Figure 4-38, external DNS can only resolve to one site, so an administrator must manually
update the DNS entries in a failover scenario. If Fabrikam could make this one Active
Directory site, it’s possible to make this configuration work for single database moves.
Outlook 2003/2007 Configured:
RPC Proxy End Point:
Certificate Priniciple Name:
Certificate Priniciple Name:
SAN Names:
SAN Names:
Outlook Anywhere Hostname:
Outlook Anywhere Hostname:
Web Service URLs
Web Service URLs
FIGURE 4-38 Fabrikam same configuration deployed in both site examples
Planning Client Access to Exchange
This configuration is very similar to the wildcard architecture except that it uses a certificate
that supports SANs. The main reasons to use this design are the expense of using a wildcard
certificate and also the maximized compatibility. Most newer clients work with wildcard
certificates, but some older clients, such as Windows mobile 5.x and some Web browsers, may
not work at all. The certificate must list all of the possible service points, and the subject name
must be set to
By default the MSSTD setting matches the ExternalHostname when enabling
Outlook Anywhere. For this architecture to work, we must change the global setting for
certprincipalname to with the following Windows PowerShell cmdlet:
Set-outlookprovider EXPR –certprincipalname
This way users will not get a certificate warning because the MSSTD setting matches the
certificate principal name in both sites. Figure 4-39 shows this architecture.
Denver U
Outlook 2003/2007 Configured:
RPC Proxy End Point: (Denver Mailboxes) (Miami Mailboxes)
Certificate Priniciple Name:
Certificate Priniciple Name:
SAN Names:
SAN Names:
Outlook Anywhere Hostname:
Web Service URLs
Outlook Anywhere Hostname:
FIGURE 4-39 Fabrikam SAN certificate and MSSTD example
Client Access in Exchange 2010
Web Service URLs
In the event of a failover, Outlook Anywhere 2007/2010 users will not see that they
are connecting to because this is automatically configured with
AutoDiscover. Outlook 2003 users will not have to change their profiles because the end point they were using still exists as a SAN on the certificate and the
Certificate Principal Name has not changed. In this case, it is possible that after a mailbox
move or site failure the user will have a Client Access server that accesses his mailbox across
sites. A total site failure in Denver would require administrators to reconfigure AutoDiscover
and mail URLs to the Client Access servers in Miami.
Another possible option is to use multiple namespaces and a hardware load balancer to route
to the correct Client Access server. This concept is demonstrated in Figure 4-40.
Outlook 2003/2007 Configured:
RPC Proxy End Point: (Denver) (Miami)
Certificate Priniciple Name:
Certificate Priniciple Name:
SAN Names:
SAN Names:
Outlook Anywhere Hostname:
Web Service URLs
Outlook Anywhere Hostname:
Web Service URLs
FIGURE 4-40 Fabrikam hardware load-balancer example
Planning Client Access to Exchange
In practice, this is a just a slightly different configuration compared to the wildcard certificate
solution. Here, the external URLs are directed to the hardware load balancer. The main advantage
in this design is that the hardware load balancer handles the upfront connection, removing the
extra processing required by the Client Access server in Denver in the other solution.
For smaller implementations, the extra cost of a hardware load balancer may be hard to
justify. However, many newer devices are available at a lower price. To fully eliminate the
hardware load balancer as a single point of failure, multiple hardware devices may be required.
An intelligent firewall and a hardware load balancer are very similar; however, the intelligent
firewall offers additional flexibility over most hardware load balancers. An intelligent firewall,
such as Microsoft’s Thread Management Gateway (TMG), can use Active Directory groups to
make decisions on how to route users, as shown in Figure 4-41.
Outlook 2003/2007 Configured:
RPC Proxy End Point:
Certificate Priniciple Name:
Certificate Priniciple Name:
SAN Names:
SAN Names:
Outlook Anywhere Hostname:
Denver AD
Web Service URLs
FIGURE 4-41 Intelligent firewall example
Client Access in Exchange 2010
Miami AD
Outlook Anywhere Hostname:
Web Service URLs
Of course, this means processes must be in place to keep group information up to date.
This also places an additional dependency on Active Directory replication to keep group
information current across sites.
Intelligent firewall is one of the more complex designs, but it can offer complimentary
features, including link translation and URL filtering. Table 4-12 summarizes the different
strategies discussed in this case study.
TABLE 4-12 Certificate Summary
Wildcard Certificate
Intelligent Firewall
Hardware Load
Same Configuration
in Both Sites
SAN Certificate
and MSSD
Only one certificate is
Wildcard certificates can be
Flexible if there are
name changes.
Some mobile and Web
clients are not compatible.
Traffic is forwarded
to the correct Client
Access server.
High complexity.
Additional hardware
Requires maintaining
group membership.
Requires multiple
Requires multiple IPs.
Additional hardware
No way to run failover site
as active.
Certificate Principal Name
is global to all Client Access
servers in forest.
Has additional security
HLB can listen for
both external names
and forward to the
correct Client Access
Highest performance
and scaling
Only a DNS A record
change is required
after site failover.
No additional hardware.
Minimal configuration
changes required after
Works with all clients.
No additional hardware.
Planning Client Access to Exchange
Fabrikam picked the SAN Certificate and MSSTD as their solution. This configuration was
beneficial because it did not require additional hardware purchases. Fabrikam was fortunate
to have enough network infrastructure between its datacenters to support the extra traffic of
supporting cross-WAN traffic.
Litware Inc. Case Study
The last case study is for the global company Litware Inc shown in Figure 4-42.
FIGURE 4-42 Litware Inc logical view
Litware Inc will implement a very similar design to Contoso, except that it will use
regional namespaces to ensure that traffic does not cross its WANs. Litware Inc will deploy
a high-availability solution within the regional datacenter, either with a software or hardware
load balancer. Only the three hub sites—Fresno, Berlin, and Tokyo—have Exchange servers.
The spoke sites, such as Kobe, Prague, and Madrid, will not have Exchange servers locally.
Figure 4-43 shows how the sites will configure their certificates and URLs. Fresno, Berlin,
and Tokyo will replace Region with the region-specific information. Tokyo, for example, will
use as their URL for OWA.
Client Access in Exchange 2010
Regional Configuration
Certificate Principal Name:
SAN Names:
Outlook Anywhere Host Name:
Web Service URLs
FIGURE 4-43 Proposed Litware Inc architecture
Case Study Summary
When planning namespaces for client access, a helpful process is to list each possible client
along with each access type or failure scenario. We can then use the information presented
earlier in the chapter to understand if our design will meet the business high-availability
As you can see in Table 4.13, be as specific as possible with the clients. Using this type of
worksheet to evaluate each client, access type, and access scenario against your design will
help ensure a successful deployment.
TABLE 4-13 Sample Design Worksheet
Outlook 2003 RPC/HTTPs
Outlook 2007
Outlook Anywhere
Planning Client Access to Exchange
Outlook 2003 internal
Outlook 2007 internal
Windows Mobile 6.x
External Outlook
Web App
Additional Resources
Outlook Anywhere Scalability with Outlook 2007, Outlook 2003, and Exchange 2007:
Exchange Remote Connectivity Analyzer:
Configuring the Blackberry Enterprise Server with Exchange 2010: http://docs
Unified Communication Certificate Partners for Exchange and OCS: http://support
Brad Hughes’s blog (script to automate Client Access server site assignment): http://
You cannot suppress the AutoDiscover redirect warning in Outlook 2007: http://
TCPView for Windows:
Automatically configure Office Outlook 2007 user accounts
Client Access in Exchange 2010
Routing and Transport
Exchange Transport Server Architecture
Understanding Transport Agents 218
Message Routing in Exchange 2010
outing messages is the most important feature of a messaging service. If your
message servers don’t deliver messages to other servers anymore, you are in deep
trouble. And that’s exactly what this chapter is about: routing and transport.
In this chapter you will learn about the Transport Server architecture, including
a detailed description of Transport server services, the queue database, the message
transport components, and how they work together. The architecture section
focuses on Hub Transport and Edge Transport servers, which function similarly. Then
you will read about transport agents and the events they can trigger. Even though
many administrators don’t use or even know about transport agents, it is good to
understand their purpose so that you can advise your users if they have a special
message-application need.
Finally, you will learn everything about message routing and the features and
functions available in Exchange 2010 to manipulate and optimize message routing.
In most situations message routing is fairly easy, and only needs special consideration in
complex organizations.
Details on the Edge Transport server especially in the areas of anti-spam and antivirus
features are covered in Chapter 7, “Edge Transport and Messaging Security.”
Exchange Transport Server Architecture
The Exchange Transport Server architecture includes several areas whose
interdependence and configuration options you should understand.
Components of Message Transport
The Transport Pipeline in Exchange Server 2010 consists of several components that work
together to route messages. There are four mechanisms to submit a message into the
transport pipeline:
SMTP Protocol SMTP servers or messaging clients can submit mail using the
standard SMTP protocol. The message enters the transport pipeline using an
SMTP Receive connector.
Store Driver Mail from Mailbox Servers is submitted via Store Driver.
Pickup/Replay Folders Properly formatted messages can be dropped into the file
system and the server will pick them up and process them.
Agent/System Generated The system can generate messages such as
Non-Delivery Reports (NDRs) or Delivery Reports, and agents can generate
messages such as Journal messages.
Figure 5-1 illustrates the Transport Pipeline and all components of a message transport to
route messages through a Hub Transport server. As described later in the chapter, not all of
these components are available for Edge Transport servers.
SMTP Receive
Pickup Directory
Replay Directory
Agent Delivery
Recipient Resolution -> Routing -> Content Conversion
Submit from:
Delivery to:
FIGURE 5-1 Message transport components
In the figure, the black arrows refer to message delivery or receiving a message; the dotted
arrows illustrate how a message is submitted or sent.
Routing and Transport
Submission Queue
When the Microsoft Exchange Transport service starts, the categorizer creates one
Submission queue on each Edge Transport server and Hub Transport server. The Submission
queue stores all messages on disk until the categorizer processes them for further delivery.
The categorizer cannot process a message unless a server promotes it to the Submission
queue. While the categorizer processes a message, it remains in the Submission queue. After
successful categorization, the message is removed from the submission queue.
Troubleshooting Submission Queue
Charlie Chung
Program Manager, Microsoft Corp, Redmond
hat’s useful about knowing that the submission queue is behind the
categorizer is that if the submission queue is growing, you need to look at
categorizer to figure out why messages are backing up. For example, most antivirus
products are registered on a categorizer event. If that agent is misbehaving, the
submission queue will grow.
On the Hub Transport server, message submission can occur through the store driver,
through the pickup or replay directory, directly by an agent, or by the Receive connector.
On the Edge Transport server, submission is generally only through the Receive connector
because messages flow in from the Internet, although pickup or replay directories exist.
Delivery Queue
Delivery queues hold messages before they are delivered to their target database. Depending
on where they should route the messages to, they are called mailbox delivery queue and
remote delivery queue.
Mailbox delivery queues hold messages that are being delivered to a mailbox server
located in the same site by using encrypted Exchange RPC. Mailbox delivery queues,
one queue for each database, exist on Hub Transport servers only.
Remote delivery queues hold messages that are being delivered to a remote server by
using SMTP. Remote delivery queues can exist on both Hub Transport servers and Edge
Transport servers, and more than one remote delivery queue can exist on each server.
On an Edge Transport server, these destinations are external SMTP domains or SMTP
connectors. On a Hub Transport server, these destinations are SMTP connectors that
are outside the Active Directory site in which the Hub Transport server is located or
a remote SMTP connector.
Exchange Transport Server Architecture
The categorizer retrieves one message at a time from the Submission queue, and always
picks the oldest message first. On Hub Transport servers, the categorizer completes the
following three steps: recipient resolution, routing resolution, and content conversation. On
Edge Transport servers the categorizer puts the message into the delivery queue and routes it
to a Hub Transport server.
Store Driver
Messages sent from mailboxes enter the transport pipeline from the sender’s Outbox.
After the message is put in the sender’s Outbox, the store driver is alerted by the Microsoft
Exchange Mail Submission service, the store driver retrieves the message from the sender’s
Outbox, and then puts it into the Submission queue on a Hub Transport server in the same
Active Directory site of the Mailbox server.
The store driver is also responsible for picking up messages that should be delivered
locally (delivered in the same Active Directory site) from a delivery queue. The store driver
puts the message in the recipient’s inbox on the respective Mailbox server.
It is important to understand that store driver is an interface between the Hub server
and the Mailbox server. That is why you see it in the beginning and the end of the Transport
Pipeline—it is used to for messages submitted by the Mailbox server and to deliver messages
to the target mailbox database.
Microsoft Exchange Mail Submission Service
The Microsoft Exchange Mail Submission service is a notification service running on Mailbox
servers. It notifies the store driver on a Hub Transport server in the local Active Directory site
when a message is available for retrieval from a sender’s Outbox.
Pickup and Replay Directory
The Pickup and Replay directories serve basically the same purpose: to process properly
formatted text files usually generated by applications into messages. The pickup directory
is used by applications or users; the Replay directory is used to resubmit exported Exchange
messages and to receive messages from foreign gateway servers. Because their purpose is
almost identical, this section only focuses on the Pickup directory. Details about the Replay
directory can be found at
The Pickup directory is another way for messages to enter the message transport pipeline
by being placed into the Pickup directory on a Hub Transport server or an Edge Transport
server. The Pickup directory is by default located under <Exchange_Installation_Path>\
TransportRoles\Pickup. It can be modified using the following cmdlet:
Set-TransportServer <Servername> -PickupDirectoryPath "C:\Pickup"
Routing and Transport
The Pickup directory is used to support legacy applications that are not capable of sending
messages using MAPI or SMTP protocol but instead by using a simple text file (extension .eml)
that is stored in the Pickup directory.
The text file has to include a certain formatting so that Exchange can compose a message
out of the text file and sent it. The following requirements must be met:
The message file must be a text file that complies with the basic SMTP message format.
MIME message header fields and content are supported.
Only one e-mail address can exist in the Sender field. Multiple e-mail addresses aren't
At least one e-mail address must exist in the To, Cc, or Bcc fields.
A blank line must exist between the message header and the message body.
The following is an example of a valid message that can be processed by the Pickup
To: [email protected]
From: [email protected]
Subject: Pickup Directory Test
This is a Pickup Directory Test
The pickup process is quite simple: you store a message as a <message>.eml file in the
directory, the Pickup directory is checked every five seconds (this cannot be changed),
and then .eml files will be processed.
The processing of messages in the pickup directory always follows the same scheme:
Rename <message>.eml to <message>.tmp. (If the file exists, the date and time are
added to the name as well.)
If the <message>.eml did not include the required formatting, the file is renamed to
After the message is successfully queued for delivery, a close command is issued,
and the .tmp file is deleted from the Pickup directory.
If the Microsoft Exchange Transport service is restarted when there are .tmp
files in the Pickup or Replay directories, all .tmp files are renamed as .eml files and are
reprocessed. This could lead to duplicate message transmission.
Exchange Transport Server Architecture
Message Queues on Transport Servers
Every message that is sent between Transport servers is temporary stored on the Transport
server in a place called a message queue. In this location, the message waits for the next
step in processing. As explained in Table 5-1, six different message queues are available
on a Transport server. You will find more details on the specific queues later in this chapter.
TABLE 5-1 Message Queues in Exchange 2010
Mailbox delivery queue
(or MAPI delivery)
Delivers messages to mailbox databases located in the
same Active Directory site. One queue is available per
database. This queue only exists on Hub Transport servers.
Remote delivery queue
On Hub Transports, delivers messages to a Hub Transport
server in a remote Active Directory site. On Edge
Transport servers, delivers messages to remote SMTP
Submission queue
Stores messages that are then processed by the
categorizer for further delivery.
Shadow redundancy queue
Copies of messages that are sent to a remote Hub
Transport that did not yet report successful delivery of
the message are stored here.
Poison message queue
Stores isolated messages that are detected to be
potentially harmful to the Exchange 2010 system.
Unreachable queue
Contains messages that can’t be routed to their
destinations, most likely because of Active Directory
replication latency or other configuration issues.
Exchange 2010 stores all queues in the queue database, which is described in the next
section. The queues itself can be managed using either the Queue Viewer or using the
Get-Queue cmdlet, as shown in Figure 5-2.
FIGURE 5-2 Viewing messages queues using the Get-Queue cmdlet
Routing and Transport
Queue Database
All message queues are stored in a single database called a queue database. The queue
database is based on the Extensible Storage Engine (ESE) database technology, which is also
used by the Mailbox Server. The queue database is made up of a database file and several log
files to record transactions. The checkpoint file tracks which transaction log files have been
committed to the database. During a service shutdown of the Microsoft Exchange Transport
service, all transaction log files are always committed to the database.
The queue database uses circular logging, which means that the history of committed
transactions that are stored in the transaction log files is not maintained. Any transaction
log file older than the current checkpoint is immediately and automatically deleted and thus
cannot be used to replay queue database recovery.
Queue Database Files
The queue database consists of several files, which are stored in the following default location:
<Exchange_Install_Path>\TransportRoles\data\Queue. Table 5-2 provides an overview of the
queue database files and their purpose.
TABLE 5-2 Queue Database Files and Purpose
This file is the queue database and stores all queued messages
after they are committed from the transaction log files.
This temporary database file is used to verify the queue
database schema on startup.
This transaction log records all changes to the queue database.
Changes to the database are first written to the transaction log
and are then committed to the database. Trn.log is the current
active transaction log file. Trntmp.log is the next provisioned
transaction log file that is created in advance. If the existing
Trn.log transaction log file reaches its maximum size of 5 MB,
Trn.log is renamed to TrnXXXX.log, where XXXX is a sequence
number. Trntmp.log is then renamed Trn.log and becomes the
current active transaction log file.
The checkpoint file. It tracks the transaction log entries that
have been committed to the database. This file is always
in the same location as the mail.que file.
These files are used to reserve emergency storage if the
transaction log volume becomes full.
Exchange Transport Server Architecture
Queue Database Configuration Options
Several configuration options exist for the queue database. Unlike Mailbox or public folder
databases, settings for the queue database cannot be configured in the Exchange Management
Console or with EMS; instead, you need to change the settings in the EdgeTransport.exe.config
file located at <Exchange_Server_Install>\Bin. If you change any settings, you need to restart
the Microsoft Exchange Transport service for the changes to take effect.
Table 5-3 provides an overview of options available to configure the queue database.
TABLE 5-3 Overview of Parameters to Configure the Queue Database
Directory of the queue database files.
If you change the directory, make sure
that the new directory exists or use the
Move-TransportDatabase.ps1 script.
Directory of the queue database log files.
If you change the directory, make sure
that the new directory exists or use the
Move-TransportDatabase.ps1 script.
Defines the number of database I/O
operations that can be grouped together
before they are executed. Default: 40.
Defines the maximum time in milliseconds
that the database will wait for multiple
database I/O operations to group.
Default: 100.
Defines the number of ESE database
connections that can be open. Default: 4.
Specifies the memory that is used to cache
the transaction records before they are
written to the transaction log file. Default:
5,242,880 bytes.
Defines the maximum size of a transaction
log file before a new log file is opened.
Default: 5,242,880 bytes.
Defines the maximum number of
background cleanup work items that can
be queued to the database engine thread
pool. Default: 32.
Enables or disables scheduled online
defragmentation. Default: $true.
Routing and Transport
Defines the time to start the online
defragmentation. Default: 1:00:00
(1:00 A.M.).
Specifies the maximum time the online
defragmentation task is allowed to run. If
the defragmentation task is not finished
in time, the queue database is left in a
consistent state. Default: 3:00:00 (3 hours).
To change the folder or drive of the queue database or log files, you can use the use
the Move-TransportDatabase.ps1 script available in the <Exchange_Server_Install>\Scripts
folder. For example, if you want to move the queue database and log files to the D:\Queue
folder, you use the .\Move-TransportDatabase.ps1 –QueueDatabasePath D:\Queue
–QueueDatabaseLoggingPath D:\Queue command.
Transport Server Services
Exchange Server 2010 installs various Windows services so that Exchange can automatically
run during startup and does not depend on administrative interaction. In most situations
you do not need to consider their purpose because they are configured automatically during
Exchange 2010 setup. However, once you face issues or a service does not start automatically
during Exchange startup, it is good to know the purpose of the service and whether there are
any implications when the service is not started.
Hub Transport Services
Table 5-4 shows the services that are added to the operating system when adding the
Exchange Server Hub Transport role to a server.
TABLE 5-4 Exchange Services for Hub Transport Role
Microsoft Exchange
Active Directory
This service reads information
from all Active Directory
partitions. The data is cached
and then used by Exchange
2010 servers to discover the
Active Directory site location
of all Exchange services in
the organization. It is also
responsible for updating the
site attribute of the Exchange
server object in Active
Runs on all Exchange servers
but Edge servers. Stopping
this service is the quickest way
to stop all Exchange services
because all other Transport
related services will also be
Exchange Transport Server Architecture
Microsoft Exchange
Anti-spam Update
This service manages the
anti-spam automatic updates
for Exchange. It installs the
Microsoft standard set of
anti-spam signature files
received by Windows
You can stop this service and
change it to service startup
manual on Hub Transport
servers that do not have or
need the Microsoft anti-spam
feature enabled. You don’t
need this service if you use
Microsoft Forefront Protection
for Exchange 2010 because it
will install its own premium
update service.
Microsoft Exchange
This service is responsible
for the EdgeSync feature to
synchronize the directory
information with an Edge
This service needs to run on
any hub transport server that
participates in an Edge
Microsoft Exchange
This service allows
applications to call the
Exchange diagnostic
This service should be started
when you consider
implementing monitoring tools
such as System Center Operations
Manager. Otherwise you don’t
need to start it.
Microsoft Exchange
Service Host
This service is the
replacement for the System
Attendant service found in
previous Exchange version
and is responsible, for
example, for calculating
The service should always be in
a running state; otherwise, the
Test-ServiceHealth cmdlet will
recognize it and report a fail.
Microsoft Exchange
Protected Service
Provides a host for several
Microsoft Exchange services
that must be protected from
other services.
This service is started
automatically and is used by
Exchange for internal
Microsoft Exchange
This is the core transport
service and is responsible for
routing messages between
This service is required for every
Hub or Edge Transport server.
Microsoft Exchange
Transport Log Search
Provides remote search
capability for Microsoft
Exchange Transport log files.
This service should be started
if you want to use the Tracking
Log Explorer or provide Delivery
Reports to your users. The CAS
servers will access it to retrieve
tracking information.
Routing and Transport
Edge Transport Services
The Edge Transport services are installed to the Windows OS during Exchange setup.
Table 5-5 lists Edge Transport–specific services (that differ from Hub Transport services)
along with their purpose and best practice information.
TABLE 5-5 Exchange Services for Edge Transport Role
Microsoft Exchange
Stores configuration data
and recipient data in AD
LDS database on the Edge
Transport server.
All other Exchange services
depend on this service, so
stopping this service is the
quickest way to stop all
Microsoft Exchange
Credential Service
Monitors credential
changes that occur in the
Exchange organization and
are replicated to AD LDS
and installs these changes
on the Edge Transport
This service is required for
every Edge Transport server.
Delivery Status Notifications
Delivery status notifications (DSNs) notify the Microsoft Exchange Server 2010 administrator
or e-mail sender of the status of a particular message. DSN messages are a critical part of
troubleshooting e-mail connectivity issues between local Exchange recipients and issues
between your Exchange organization and the remote e-mail servers on the Internet.
DSN messages occur with the following error code areas:
4.x.x This indicates a temporary problem where for example a mailbox server was
unavailable and typically resolve themselves.
5.x.x This status code indicates a permanent problem and results in a Non-delivery
Report (NDR) being sent to the originator of the message.
For messaging administrators the 5.x.x DSN status codes are the more interesting ones for
troubleshooting for example. Table 5-6 provides a description of important DSN status codes.
TABLE 5-6 Overview of 5.x.x DSN Status Codes
Bad destination mailbox address. E-mail address or domain does
not exist.
Destination mailbox address ambiguous. Two or more recipients
in the Exchange organization have the same address.
Exchange Transport Server Architecture
Mailbox full. The recipient’s mailbox has exceeded its storage
quota and is no longer able to accept new messages.
Message too big for system. The message exceeds the size limit
Routing loop detected. A configuration error has caused an
e-mail loop.
Too many recipients. The total of recipients of the message
exceeds the total number of recipients allowed in a single message.
Delivery not authorized. The sender of the message is not allowed
to send messages to the recipient.
Unable to relay. The sending e-mail system is not allowed to send
messages to an e-mail system where that e-mail system is not the
final destination of the message.
Client was not authenticated. The sending e-mail system did not
DSN messages and DSN codes are commonly configured either to modify the DSN
message or to configure what DSN codes are copied to the Postmaster mailbox.
Modifying DSN Messages
Exchange 2010 is extremely customizable with regard to system messages and allows you
to modify any DSN message using the New-SystemMessage cmdlet. You can define the DSN
message, the language that is used, and whether the message is available internally only.
For example, to configure a custom text message for the DSN code 5.1.1 use the following
New-SystemMessage -DSNCode 5.1.1 -Text "E-Mail Address does not exist" -Internal $false
-Language En
Customizing your DSN message is quite a timely effort. However, when your company’s
policy requires displaying custom system messages—for example, to provide user guidance—
you can use this feature.
Creating DSN Message Copies
By default Exchange does not keep a copy of DSN messages but instead discards them
automatically to preserve space. In some situations you will want to receive a DSN message
to understand your messaging system. For example, when you’re migrating from a different
e-mail system and you just created all mailboxes with their respective original e-mail
addresses, you may want to verify which e-mail addresses are not yet available in the system.
Therefore, you’d want to determine which e-mail addresses are currently rejected.
Routing and Transport
If you want to keep DSN messages, you first need to configure the Exchange Recipient
Reply Recipient (also known as Postmaster mailbox) using the following cmdlet:
Set-OrganizationConfig -MicrosoftExchangeRecipientReplyRecipient <PostmasterMailbox>
Then you need to specify the DSN status codes for which you want Exchange to send DSNs
to the Postmaster mailbox. This is done using a cmdlet such as the following:
Set-TransportConfig -GenerateCopyOfDSNFor 5.1.1
In an Exchange organization with EdgeSync, all these settings are configured
on a Hub Transport server in your Exchange organization, not on the Edge Transport
servers. If you run Edge Transport servers without EdgeSync, you need to configure the
Set-TransportConfig –ExternalPostmasterAddress <E-Mail Address> cmdlet as well.
Message Latency Measurement
New to Exchange 2010 is the ability to measure service levels for messages that flow through
the system. Latency measurements are implemented into the core transport service and
logged in Message Tracking.
Exchange 2010 comes with the ConvertTo-MessageLatency.ps1 script (found in the
<Exchange_Install_Path>\Scripts folder) that extracts server and end-to-end latency
information from the tracking log. It can be used to convert the data structure of a tracking
log event to present a more friendly presentation of the component latency data. Thus you
can use the script to identify messages why they’ve taken a long time to deliver to the users
and what Hub Transport servers caused the delay. An example is found in Figure 5-3.
FIGURE 5-3 Running the ConvertTo-MessageLatency.ps1 Script
Additionally, the tracking logs are processed automatically and are summarized in log files
located in the following directories found under <Exchange_Installation_Path>\
TransportRoles\Logs on each transport server:
ActiveUserStats (exported every eight hours)
ServerStats (exported every hour)
Exchange Transport Server Architecture
The logs are in CSV format and are automatically produced to provide statistics for a single
server. You can thus use Microsoft Excel to look at the log files.
If you use System Center Operations Manager (SCOM), including the Exchange
Management Pack (MP), the log files are aggregated to the System Center data warehouse
database. This is where the reports are generated. These reports show hourly and daily server
statistics as well as active users and distribution group usage.
Shadow Redundancy
Exchange Server 2010 introduces the shadow redundancy feature, which provides
redundancy for messages for the entire time they are in transit. Copies of messages that are
submitted to a Hub Transport server are stored in the transport queue until the next hop
reports successful delivery of the message. If the next hop doesn’t report successful delivery
and it fails, the message is resubmitted for delivery. Shadow Redundancy is actually made of
three shadowing techniques:
Shadow Queue Stores messages not yet confirmed by the next hop to be delivered.
Delayed Acknowledgment (Transport Wormhole) The connections are held
open until the delivery is confirmed on the next hop.
System Generated Reference Count Includes a pattern to ensure that
system-generated messages are also copied to the shadow queue.
The Shadow Redundancy Manager (SRM) is the core component of a Transport server that
is responsible for managing shadow redundancy. The SRM is responsible for maintaining the
following information for all the primary messages that a server is currently processing:
The shadow server for each primary message being processed
The discard status to be sent to shadow servers
The SRM is responsible for the following actions for all the shadow messages that a server
has in its shadow queues:
Maintaining the list and checking primary server availability for each shadow message
Processing discard notifications from primary servers
Removing shadow messages from the database once it receives all expected discard
Deciding when the shadow server should take ownership of shadow messages, thus
making it the primary server
Figure 5-4 shows how shadow redundancy keeps a copy of the messages that have not yet
been delivered by the Hub Transport server located in the Active Directory site Site-Fresno.
As soon as the Hub Transport in Fresno is able to send the message to the next hub, the Hub
Transport located on Berlin-Ex01 receives an acknowledgment and will remove the messages
from the shadow redundancy queue.
Routing and Transport
FIGURE 5-4 Shadow Redundancy Queue in Queue Viewer
Shadow redundancy is a high-availability feature; you will find more information, including
configuration options, in Chapter 11, “Designing High Availability.”
Message Throttling
Message throttling is a new feature of Exchange 2010 that implements limits on Hub
Transport or Edge Transport servers to prevent accidental or intentional inundation of system
resources. These limits are defined on areas such as the number of messages or connections
that are processed by the Transport server.
Message throttling involves limits on message processing rates, SMTP connection rates,
and SMTP session timeout values. These limits protect the Transport servers from being
overwhelmed by accepting and delivering too many messages or connections.
Message throttling is enabled by default but you can adapt message throttling options
on the Transport server, the Send connector and Receive connector. Options that you can
define include the MaxConcurrentMailboxDeliveries parameter on Transport servers and the
MaxInboundConnection and MaxProtocolErrors parameters on Receive connectors.
Exchange 2010 Service Pack 1 adds Delivery Class Throttling to the feature set. This adds
the ability to classify a message based on certain characteristics and assign it a delivery class.
Throttling will investigate messages when they are sent by individual users and add a cost to
each message based on message size, number of recipients, and frequency. This cost factor
allows assigning a delivery class to the messages.
The behavior is similar to postal mail. First-class mail gets delivered faster than regular
postage mail. The higher the delivery class, the higher the message priority is in the
connector queue. For example, Delivery Class Throttling will prioritize small messages with
just a couple of recipients over large bulk messages with many recipients in the message
Exchange Transport Server Architecture
For more information about message throttling, including all available message throttling
options, see
Back Pressure
Back pressure is a system-resource monitoring feature of the Microsoft Exchange Transport
service available on the Hub Transport or Edge Transport server role.
Back pressure monitors important system resources, such as available hard-disk drive
space and available memory. If utilization of a system resource exceeds the specified limit,
the Exchange server stops accepting new connections and messages. This prevents system
resources from being completely overwhelmed, and enables the Exchange server to deliver
the messages queued to be sent. When utilization of the system resource returns to a normal
level, the Exchange server accepts new connections and messages.
For each monitored system resource on a Hub Transport server or Edge Transport server,
the following three levels of resource utilization are applied:
Normal The resource is not overused. The server accepts new connections and
Medium The resource is slightly overused. Back pressure is applied to the server in
a limited manner. Mail from senders in the authoritative domain can flow. However,
the server rejects new connections and messages from other sources.
High The resource is severely overused. Full back pressure is applied. All message
flow stops, and the server rejects all new connections and messages.
Because Microsoft does not recommend modifying any back pressure settings,
parameters were not included in this section, but you can access them at http://technet You configure back pressure settings in the
EdgeTransport.exe.config file located at <Exchange_Server_Install>\Bin.
Understanding Transport Agents
Transport agents allow you to install custom software on a Hub or Edge Transport server role
in Exchange Server 2010. Based on an action when a message flows through the transport
pipeline, the software then can process messages. The backscatter agent, is an example
of a transport agent.
Transport agents have full access to all e-mail messages that they
encounter. There are no restrictions on a transport agent’s behavior. Transport agents that
are unstable or contain security flaws may affect the stability and security of Exchange. Do
not install transport agents that haven’t been fully tested in a test environment!
Routing and Transport
Default Transport Agents
Exchange Server 2010 includes several transport agents that enable it to provide additional
features such as rights management service (RMS) or journaling. Table 5-7 lists default
transport agents sorted by Hub Transport and Edge Transport server roles.
TABLE 5-7 Default Transport Agents
Transport Rule agent
Connection Filtering agent
RMS Encryption agent
Address Rewriting Inbound agent
RMS Decryption agent
Edge Rule agent
Prelicensing agent
Content Filter agent
Journaling agent
Sender ID agent
Journal Report Decryption agent
Sender Filter agent
Text Messaging Routing agent from Text
Messaging Delivery Agent Connector
Recipient Filter agent
Protocol Analysis agent
Attachment Filtering agent
Address Rewriting Outbound agent
You can get a list of all transport agents currently configured on an Exchange Transport
server by running the Get-TransportAgent cmdlet. For a list of Transport Agents that have
been used to process messages since the last time the transport service was restarted, use the
Get-TransportPipeline cmdlet as shown in Figure 5-5.
FIGURE 5-5 Default Transport Agents on a Hub Transport server
Understanding Transport Agents
Events That Trigger Transport Agents
Exchange 2010 Transport agents use SMTP events to trigger the agent when a message
moves through the transport pipeline. Three areas can trigger events: SMTP Receive events,
Categorizer events, and Connection Manager events.
Even though all events available are listed in the following subsections, this chapter does
not explain in detail how to develop a transport agent, but merely provides an overview of
what you can do using Exchange 2010. More information about Transport Agents can be
found at
SMTP Receive Events
SMTP Receive events are triggered whenever an SMTP connection is made or an SMTP
command is sent, as listed in Table 5-8. Using SMTP Receive events you can interact with the
system at almost every stage of an SMTP communication.
TABLE 5-8 SMTP Receive Events Overview
This event is triggered upon initial connection from a
remote SMTP host.
This event is triggered when the EHLO SMTP verb is
issued by the remote SMTP host.
This event is triggered when the HELO SMTP verb is
issued by the remote SMTP host.
This event is triggered when the AUTH SMTP verb is
issued by the remote SMTP host.
This event is triggered when the remote SMTP host has
completed authentication.
This event is triggered when the MAIL FROM SMTP verb is
issued by the remote SMTP host.
This event is triggered when the RCPT TO SMTP verb is
issued by the remote SMTP host.
This event is triggered when the DATA SMTP verb is issued
by the remote SMTP host.
This event is triggered when the remote SMTP host as
completed submitting the e-mail message headers.
This event is triggered when the remote SMTP host issues
<CRLF>.<CRLF>, which indicates the end of data.
Routing and Transport
This event is triggered when the HELP SMTP verb is
issued by the remote SMTP host. This event can occur at
any time after the OnConnect SMTP event and before the
OnDisconnect SMTP event.
This event is triggered when the NOOP SMTP verb is
issued by the remote SMTP host. This event can occur at
any time after the OnConnect SMTP event and before the
OnDisconnect SMTP event.
This event is triggered when the receiving SMTP host
issues a temporary or permanent delivery status
notification (DSN) code to the sending SMTP host. This
event can occur at any time after the OnConnect SMTP
event and before the OnDisconnect SMTP event.
This event is triggered when the RSET SMTP verb is issued
by the sending SMTP host. This event can occur at any
time after the OnConnect SMTP event and before the
OnDisconnect SMTP event.
This event is triggered upon disconnection of the SMTP
conversation by either a receiving or sending SMTP host.
Categorizer Events
The Categorizer events are triggered when a message enters, is processed by, or leaves the
categorizer, as listed in Table 5-9.
TABLE 5-9 Categorizer Events Overview
This event is triggered upon submission of a message into the
Submission queues on the receiving SMTP host. All messages
encounter this event whether they arrived via SMTP submission,
MAPI submission, or the Pickup or Replay directories.
This event is triggered after all the recipients have been
resolved but before the next hop has been determined for
each recipient. The OnResolvedMessage routing event enables
subsequent events to override the default routing behavior by
using the per-recipient SetRoutingOverride method.
This event is triggered after messages have been categorized,
distribution lists have been expanded, and recipients have
been resolved.
This event is triggered when the Categorizer completes
processing the message.
Understanding Transport Agents
Connection Manager Events
Connection manager events are only available to delivery agents such as the Text Messaging
Routing agent from Text Messaging Delivery Agent Connector. As mentioned previously
in this chapter, delivery agents should succeed Foreign Connectors because they are more
flexible. Table 5-10 provides an overview of the events raised by the connection manager
TABLE 5-10 Connection Manager Component Events Overview
This event is raised when there are messages in the queue to
be delivered to the foreign system. It notifies the delivery
agent to initiate a connection to the foreign system.
This event notifies the delivery agent to retrieve the
next item from the queue.
This event is raised when there are no more messages in the
queue to be delivered to the foreign system. It notifies the
delivery agent to close the connection to the foreign system.
Message Routing in Exchange 2010
Message routing might seem very easy in small organizations like the one in the Contoso
scenario, but it gets more complex as the organization grows. For larger organizations,
like the Litware scenario described in this book, you definitely have to understand all the
possibilities and parameters available to you for planning, configuring, and optimizing
message routing.
Message Routing within an Exchange Organization
In Exchange versions prior to 2007 you defined message routing inside an Exchange
organization by using routing groups and routing group connectors. Exchange Server 2007
introduced changes to internal message routing that are still valid for Exchange 2010:
The message-routing topology and routing decisions are based on the Active
Directory site topology (Active Directory sites and IP site links).
Routing is configured automatically, so you do not need to configure any routing
group connectors.
The SMTP protocol is used for all message transport.
Routing and Transport
NOTE Exchange Server 2010 automatically creates internal Send connectors on Hub Transport
servers that are required for mail flow within the organization. These are implicit connectors
that are not visible in the Exchange management tools, and you cannot modify them.
Table 5-11 provides an overview of internal message routing in Exchange Server 2007
and Exchange Server 2010 as it correlates to Exchange 2000 and Exchange 2003.
TABLE 5-11 Routing Comparison Between Exchange Versions
Hub Transport server
Dedicated bridgehead server
Active Directory site
Routing group
IP site link
Routing group connector
Cost of IP site link
Cost of routing group connector
This chapter only describes routing between Exchange Servers that are either 2007 or
2010. Routing between Exchange Server 2010 and Exchange 2003 is explained in Chapter 14,
“Upgrading from Exchange Server 2003 and Exchange Server 2007.”
Point to Point Routing in Exchange 2010
The Hub Transport server role is the only Exchange server role that can route messages within
an Exchange organization. Of course, the Edge Transport role can also route messages, but
only to and from the Internet.
Since Exchange Server 2007, all messages in Exchange 2010 flow through a Hub
Transport server, even if the recipient is on the same Mailbox server as the sender.
Internal message routing in Exchange Server 2010 is also known as Point to Point routing
and follows two basic rules:
If the message target recipient is within the same Active Directory site, the Hub
Transport server delivers the message directly to the Mailbox server where the
recipient mailbox resides.
If the message is addressed to a recipient located in a different Active Directory site,
the Hub Transport server sends it directly to a Hub Transport server in the target Active
Message Routing in Exchange 2010
Directory site. This means that the message does not relay to each Active Directory site
along the least-cost routing path as Exchange versions before 2007 did! It will choose
the target Hub Transport server using round-robin load-balancing mechanisms. Only
if the selected Hub Transport server becomes unavailable will it choose another Hub
Transport server.
By default Hub Transport and Edge Transport servers communicate with each other
using TLS over SMTP. This means that the communication between the servers is always
encrypted, even if the message transmitted is not encrypted. TLS uses the local digital
certificate available on the Exchange server. If you did not configure a certificate it uses the
self-signed certificate that was created when Exchange was installed.
Most large-scale network environments are complex, so some situations require special
configurations. What happens when the target Active Directory site is offline because of
network problems? What happens to firewall settings where network traffic is forced to flow
through specific Active Directory sites? These issues are covered in the following paragraphs.
Disable TLS for Hub to Hub Transport Communication
Andy Schan
Senior Consultant, Schan Consulting Inc., Canada
y default Hub Transport to Hub Transport communication is encrypted using
TLS. However, if your company uses WAN Optimizing Controller (WOC) devices,
you might want to turn off TLS to optimize the WAN traffic using this device.
Exchange 2010 now supports disabling TLS to support this scenario. If you have
a specific WAN link you want to disable TLS for, you basically configure a Hub
Site for both Active Directory sites (the Active Directory sites between the link)
so that no messages are sent directly to the target site but stop before the link
with the WOC device. Then you create new Receive connectors for both sites using
the IP address range of the distant site and configure the Receive connectors to
disable TLS.
Now all messages that want to use the WAN link are sent without using TLS
encryption; thus the WOC device can optimize the traffic. You can find more details
how to configure it at
Routing and Transport
Exchange 2010 Version-Based Routing
Exchange Server 2010 also implemented a new transport server routing rule called
Version-Based Routing or just Versioned Routing. This rule means that a Hub Transport can
only communicate with a Mailbox server role of the same Exchange version. The idea behind
version-based routing is that different and incompatible versions of the Exchange API used
to get messages in and out of the store are implemented in Exchange 2007 and 2010.
An Exchange 2010 server cannot talk directly to an Exchange 2007 mailbox server and vice
versa. However, the Hub Transport servers of both versions can communicate together.
If you have Exchange 2007 and Exchange 2010 servers in your organization located in
the same Active Directory site, the rule prevents Exchange 2007 Hub Transport servers
from directly communicating with Exchange 2010 Mailbox servers and Exchange 2010 Hub
Transport servers from communicating to Exchange 2007 Mailbox servers.
In the Fabrikam scenario this will be the situation during migration. During that time,
all messages sent from Exchange 2007 mailboxes to Exchange 2010 mailboxes will be sent
from the Exchange 2007 Mailbox server to the Exchange 2007 Hub Transport, and from
there will be transferred to the Exchange 2010 Hub transport and then to the Exchange 2010
Mailbox server.
Version-based routing was implemented to overcome the requirement to have separate
Active Directory sites for Exchange 2010 servers.
Least-Cost Routing Path
When multiple routing paths exist for a message, the routing path is calculated based on
an algorithm to select a single path over which the message will be routed. This is called
least-cost routing path calculation and it uses the following logic:
Calculate the cost to the target Active Directory site by adding all IP site link costs or
connector costs between the source and the target site. If an Exchange cost is configured
on an IP site link, the Exchange cost is used instead of the Active Directory cost. If there
are multiple paths, only the path with the lowest aggregated cost will be used.
If there are multiple paths with the same lowest aggregated costs, the routing path
with the fewest hops is selected.
If multiple paths are still available, the site name with the lowest alphanumeric name is
selected. Starting with the site name to the target Active Directory site, the algorithm
will go backward along the path until it finds a site name that doesn’t match.
Other factors, such as message size limits or connector scope, can influence the
least-cost routing path.
The two concepts described in the following sections are based on the least-cost routing
path: queue at point of failure and delayed fan-out.
Message Routing in Exchange 2010
If a Hub Transport server cannot deliver a message to a Hub Transport server in the
destination site, the Hub Transport server uses the least-cost routing path to deliver the
message as close as possible to the destination site. This is called queue at point of failure.
Technically, the least-cost routing path will be used in reverse order: from the destination
Active Directory site to the source Active Directory site. All Active Directory sites are
contacted along this path, and if a Hub Transport server is available, the message is queued
there in a retry state. Thus the message is delivered to a Hub Transport server that seems
to be the closest one to the target Hub Transport server from the IP site link cost perspective.
If Hub Transport servers are not available in any site along the least-cost route, the message
is queued on the local Hub Transport server.
For example, use the Litware scenario and assume all site link costs are the same and the
links are configured exactly as shown in Figure 5-6.
FIGURE 5-6 Litware Active Directory site scenario
Now a message is sent from Madrid to Houston. Normally the Hub Transport server of
Madrid would directly connect to a Hub Transport server in Houston to submit the message.
However, if no Hub Transport server in Houston is reachable, the message cannot be sent
Queue at point of failure takes place and the closest site to Houston that has Hub
Transport servers is selected. In this example, the message is transferred to a Hub Transport
server in Fresno because Fresno is closer to Houston than Madrid.
Routing and Transport
When sending a message that is addressed to multiple recipients, point-to-point routing
normally means creating a copy of the message for every Exchange server that hosts
a recipient and sending the message to the target Hub Transport servers directly. However,
Exchange Server 2010 uses a technique called delayed fan-out to preserve bandwidth when
routing messages with many recipients.
After each recipient has been resolved by the Hub Transport server, Exchange Server 2010
compares the routing path for each recipient. The splitting of messages into multiple copies
does not occur until a Hub Transport server is reached, which splits up the routing path.
Microsoft calls such a Hub Transport server a fork in the routing path.
Take a look at the Litware scenario in Figure 5-6. A message is sent from Madrid to
recipients in Fresno, Houston, and Anaheim. Because of delayed fan-out, a single message
is then transferred to Fresno, where the local Hub Transport delivers a local copy to the
Fresno recipient, then creates two copies of the message, sending one to Houston and one
to Anaheim. As you can see, especially for messages with large numbers of recipients, this
feature saves a lot of bandwidth.
External Routing Connector Selection Process
Exchange 2010 also needs to decide what Send connector it will use to route messages that
are destined to the organizational parameter network such as the Internet. This selection
process is done by first eliminating all connectors whose message size restrictions are less
than the size of the message to be routed and then determining a single connector using the
following steps:
The connector must be enabled; if the connector is a scoped send connector, it must
be in-scope for the local Hub Transport server and the address space must include the
recipient’s domain. (In other words, the connector must appear in the hub transport
server’s routing table.)
If more connectors remain, the most specific address space match will be used.
If still more than one connector matches, the following logic will be used until a unique
connector is identified:
a. Connector cost (All IP site link costs are aggregated.)
b. Proximity (A local server is chosen over another Hub Transport server in the same
Active Directory site, and a server in the local Active Directory site is chosen over
a source server in a remote Active Directory site.)
Alphanumerically (The lowest connector name will be used—for example,
ConnectorA will be preferred over ConnectorB.)
Remember that this selection process takes place at every Hub Transport server
along the routing path used by the message. If there is a scoped connector along the
least-cost routing path available that includes the address space, the route may change
when the message is routed through this Active Directory site.
Message Routing in Exchange 2010
Routing Table
Every Hub Transport or Edge Transport server calculates the routing topology based on the
Active Directory configuration. This includes Active Directory sites, Active Directory site links,
Exchange servers and their relation to Active Directory sites, SMTP connectors, third-party
connectors, mailbox and public folder stores, and legacy Exchange 2003 routing groups
and connectors. This will make up what is called the routing table. A routing table is built
every time one of the following events occurs:
The Microsoft Exchange Transport service is started.
After a periodic reload interval (six hours by default).
After Active Directory change notifications such as changes in Active Directory site
All Active Directory changes are collected into a batch to process them in a single
operation. Each notification causes a five-second delay; thus if many changes occur at the
same time, routing calculation is delayed until all changes are received and then processed
as a single operation.
By default, the routing table log files can be found in <Exchange_Installation_Path>\
Using the Set-TransportServer cmdlet as listed in Table 5-12, you can configure a few
parameters to configure the routing table creation.
TABLE 5-12 Set-TransportServer Options for Routing Table Configuration
Specify the location of the routing table log files.
Specify a maximum size for the directory that
contains routing table log files. Default: 50 MB.
Specify a maximum age for the routing table
log files. Default: 7 days.
In addition to these parameters, you can configure the periodic interval the routing
table is automatically recalculated using the RoutingConfigReloadInterval parameter in the
EdgeTransport.exe.config file. By default, this is set to 12 hours but because every Transport
server renews its Kerberos token after 6 hours, the routing table is created more frequently.
This means that other parameters interfere with changing the RoutingConfigReloadInterval
parameter, so you should be careful when changing it.
You can view the Routing Table logs using the Routing Log Viewer available in Exchange
Management Console. You can find more information how to use the Routing Log Viewer in
the “Verifying Configuration Using the Routing Log Viewer” section later in this chapter.
Routing and Transport
Reviewing and Configuring Message Routing
Between Active Directory Sites
Hub Transport servers route messages to other Hub Transport servers based on the Active
Directory site and site link topology. Therefore, for Exchange 2010 to work correctly, it is
crucial that the Active Directory topology does not cause any negative effects on message
routing or Exchange servers. This section focus on how to make sure that your Active
Directory site topology is suitable for Exchange 2010 and what you can do to modify the
topology with Exchange-related settings.
Review Active Directory Site and Site Links Topology
Before you consider configuring Active Directory sites and Active Directory site links to
optimize message routing, you need to clearly understand the current Active Directory
topology of your organization. You can do this using the Active Directory Sites and Services
snap-in. However, in a large environment with many Active Directory sites and site links,
you may lose the overview. For that reason you can also use a tool called Microsoft Active
Directory Topology Diagrammer that allows you to visualize the Active Directory topology
in a Microsoft Office Visio file. The tool was tested with Visio 2003 or Visio 2007. Having
a graphical representation that you can put on the wall helps you to identify areas that might
need to be optimized for message routing. Figure 5-7 shows an example of a diagram created
from the Litware Scenario. The tool can be downloaded at
FIGURE 5-7 Sample Active Directory topology diagram from the Litware scenario
Configuring Active Directory Sites
An Active Directory site is a logical definition of a physical connected network, normally
based in the same local area network (LAN) and thus sharing a very fast network connection
within the Active Directory site. You define a site based on an IP subnet in the Active
Message Routing in Exchange 2010
Directory Sites and Services snap-in. The primary purpose for creating an Active Directory site
is to define which subnets in the network are connected in a way that optimizes control of
Active Directory replication traffic.
The Active Directory site is a routing boundary for Hub Transport servers to make routing
decisions based the Active Directory site topology as described in the previous chapter. To
meet this requirement you must make sure that every Exchange server role belongs to an
Active Directory site. You should also verify that each Active Directory site is based on one
or more subnets based on LAN-quality networks. Otherwise, consider splitting these Active
Directory sites into multiple sites.
You can get a list of all Exchange servers and their respective Active Directory site using
the following cmdlet: Get-ExchangeServer | ft Name, Site.
Many companies split the administration between the Active Directory forest and
Exchange into different teams. If this describes your situation, you need to remember
that you can only configure Active Directory sites and Active Directory site links if the
Active Directory team has provided you with sufficient permission and you have secured
the buy-in from that team to make the changes to the production Active Directory
Configuring Site Links and Site Link Costs
Site links are logical paths between Active Directory sites and always include a site link cost
to be able to configure specific routes for Active Directory replication traffic. The same
information is used by Exchange 2010 to calculate the least-cost routing path.
Site links are only used for routing when direct Hub Transport server to Hub
Transport server connections are not possible. The vast bulk of deliveries occur via direct
A site link does not force the actual path that is taken by network packets on the physical
network but define the way Active Directory replication is done within the forest. However,
every so often the cost assignment to the site link typically relates to the underlying network
speed and available bandwidth.
It is important for the Exchange designer to understand the site topology as well as the
site links and site link costs to make sure that Exchange routing is done as defined. To verify
how Exchange uses the current topology, you can use the Routing Table Log Viewer after the
first Exchange 2010 server is installed in the forest. If an Exchange server is not yet installed,
use the Microsoft Active Directory Topology Diagrammer to get an Active Directory topology
Routing and Transport
A Practical Way to Define Site Link Costs
Brian Day
Senior Systems Administrator, Messaging & Directory Services, Commonwealth of Massachusetts
ctive Directory site link costs: What can they cost you? Misconfigured site link
costs can cost you hours of frustration if not planned correctly from the start.
In 2005 I joined an employer whose Active Directory architecture was very complex
across hundreds of physical sites, and a little bit out of control. It grew faster than anyone
expected and some things got overlooked, including site link configuration. Part of my
role was to help clean up the environment and optimize it where possible. At the time,
WAN connections for these hundreds of sites were primarily all frame relay, ranging in
speeds from 384 Kbps to multiple T-1 circuits bonded together. Site link costs were of
the Wild West variety, with no uniformity. Values existed from more than 1,000 all the
way down to 10 and anything in between, even though we only had 5 or 6 different
speed links. In many cases circuits of the same speed didn’t have the same costs. Taking
a step back and looking at the situation I could see what had happened—there was no
proper planning for the future and multiple schemes were actually in use regarding site
link cost, depending on who had originally entered the site links.
I knew I had to find a way to future-proof ourselves and come up with a way to
deal with new WAN connections in the future without having to go back and
reconfigure old ones every couple of years. While researching methods other
people use to determine costs I found a great article on Microsoft TechNet called
“Determining the Cost” available at
cc782827(WS.10).aspx. Buried on this page was a formula Microsoft suggested for
site link costs: [1024/Log10 (Kbps of WAN Link)]=Cost. At first glance I looked at this
and thought, What mathematics nerd had too much time on his hands? That is,
until I gave it an honest try.
Suddenly I had a desire to call my old math teacher and let him know that
logarithms did actually end up being useful in the real world! As you can see in
Table 5-13, the formula provided us with costs that can grow (and shrink) as WAN
speeds matured, becoming faster and faster. It also left enough space between
costs so that I could configure primary/secondary site links by creating a second
site link with a value of Cost+1. I’ve often seen people establish costs with no space
between them, leaving no room for this type of configuration. Perhaps if you have
other finicky site links that have the speed but are not always the most reliable (like
a satellite connection) compared to other site links of similar throughput, you could
also adjust them by bumping the cost a couple points. I have a sneaking suspicion
that I will be gone from this planet by the time WAN connections exist that are fast
enough to cause this formula to reach the lowest value of 1.
Message Routing in Exchange 2010
TABLE 5-13 Site Link Costs Defined by Bandwidth
10 Mbps
100 Mbps
1000 Mbps
Configuring Exchange Specific Settings for Site Links
The Active Directory site topology might not be optimal for Exchange message routing
in specific cases. Therefore, you can assign an Exchange-specific cost to the site link that
Exchange can use for routing purposes. The Exchange-specific cost for the IP site link will not
modify or affect the current Active Directory site cost that is used for replication. Of course,
if you set an Exchange cost, you will override the Active Directory cost for message-routing
purposes, but this won’t interfere with Active Directory replication.
After reviewing your Active Directory site topology and installing your Exchange servers in
the right Active Directory sites, you should carefully consider whether you need to implement
Exchange-related IP site link costs, which are quite hard to manage. They only make sense
in large deployments where you have many Active Directory sites with Active Directory site
links that are not in the control of Exchange and are known to be changed without your
notification. Don’t try to configure a message routing path—remember that most of the time
the Hub Transport servers communicate directly to each other anyway.
Consider the Litware Scenario where the IP Site Link SiteLinkWorld is configured
with a cost of 100. The following Exchange Management Shell (EMS) cmdlet assigns
an Exchange-specific cost of 20 to it:
Set-ADSiteLink -Identity “SiteLinkWorld” -ExchangeCost 20
Routing and Transport
You can also use the Set-AdSiteLink –Identity <ADSiteLink> – MaxMessageSize
<value> cmdlet to assign a maximum message size limit for messages sent between
Active Directory sites. This is especially useful if you have branch offices that have
low-bandwidth network links so that you make sure only small messages can be sent
over the network. All the larger messages will generate a non-delivery report (NDR).
As shown in Figure 5-8, the Active Directory site link still has the Active Directory cost
of 100, but additionally has an Exchange cost of 20 assigned, and a message size limit is not
configured. From now on, least-cost routing calculation will consider only the Exchange cost
and ignore the Active Directory cost.
FIGURE 5-8 Active Directory site link with exchange costs assigned
Using Exchange Costs on IP Site Links
Ulf Hansen
Principal Systems Administrator, Central Administration Exchange, Siemens AG (Germany)
y company has a very large forest with more than 1,000 different Active
Directory sites and many hundreds of IP site links. Domain administration is
done independently and administrators have a huge influence on configuring their
Active Directory sites because Active Directory sites are also used for services other
than Exchange. Thus we started first to think about building Active Directory sites
just for Exchange to be in charge of the routing costs, but finally decided against it.
Because we were not in charge of defining the Active Directory costs and we did not
want to interfere or change our complex Active Directory routing in any way, we
agreed to configure all Active Directory sites automatically with the maximum cost
of 999. As a result, Exchange considers all Active Directory sites equal and uses the
route with the fewest hops as the least-cost route.
Message Routing in Exchange 2010
Remember, Exchange costs will be used over Active Directory costs, and if multiple
paths are available with the same costs, the path with the fewest hops is selected
if a direct connection to a Hub Transport server in the target Active Directory site
cannot be made.
We discovered that messages didn’t take the route that we anticipated; our solution
was to reduce the Exchange cost to force messages and correct the routing.
However, we still see some limitations when Active Directory costs are used that
cause problems in our Exchange environment. For example, Public Folder stores
that have an AD cost of more than 500 from the Exchange server are not considered
for Outlook 2003 Free/Busy Public Folder lookups.
Configuring Hub Sites
One way to interfere with the least-cost routing path is by defining hub sites through which
all message flow must be relayed. You can think of this situation as a form of hub-and-spoke
design with a messaging backbone.
You might have hub sites if a firewall prevents direct communication between certain
Active Directory sites or if a company policy exists whereby all message traffic must be routed
through a special Active Directory site.
A hub site is considered only when it is located on the least-cost routing path
calculated by the Hub Transport server. The source Hub Transport server always calculates
the lowest-cost route first, and then determines whether any of the sites on the route are
hub sites. If the lowest-cost route does not include a hub site, the Hub Transport server will
directly connect to a Hub Transport server in the target site.
Before you implement hub sites, it is important that you review your Active Directory
topology to make sure that the least-cost routing path always includes the Active Directory
sites you want to define as hub sites.
You can view all hub sites available using the Get-AdSite cmdlet and configure them using
the Exchange Management Shell and the Set-AdSite cmdlet. You have to do this site by site,
so keep track of the changes you make!
The following cmdlet shows an example where Site-Berlin is configured as a hub site:
Set-AdSite -Identity „Site-Berlin“ -HubSiteEnabled $true
Configuring Expansion Servers for Distribution Groups
You also can modify the default routing topology by assigning expansion servers for
distribution groups. By default, when a message is sent to a distribution group, the first Hub
Transport server that receives the message expands the distribution list and calculates how to
route the messages to each recipient in the list.
Routing and Transport
If you configure an expansion server for the distribution list, all messages sent to the
distribution list are sent to the specified Hub Transport server, which then expands the list
and distributes the messages. For example, you can use expansion servers for location-based
distribution groups to ensure that the local Hub Transport server resolves them. This
configuration only sends one message addressed to a location-based distribution to the
location and is then expanded at the target location by the defined expansion server.
Because you only can define a single Hub Transport server, distribution
list expansion will fail if this expansion server is not available. Thus you might negatively
impact your message flow. There is no way to configure more than one expansion server,
so you have to decide either to use one expansion server or let the distribution list expand
at all servers.
Even though distribution group expansion was available in previous Exchange versions,
it is improved in Exchange 2010 in two ways: You can now configure a memory caching
limit to prevent the cache from consuming too much memory, and the processing of large
distribution groups with delivery restrictions is done more efficiently.
You configure the distribution group cache by adding the parameters as found in
Table 5-14 to the EdgeTransport.exe.config file located at <Exchange_Server_Install>\Bin.
TABLE 5-14 Parameters to Configure Distribution Group Cache
This cache is only used to avoid duplicate
delivery to one-offs and distribution lists
(DLs). So if you notice that delivery to some
DLs (with more entries than this cache size)
still result in duplicate deliveries, you can
make the size larger. The Information Store
would still do duplicate detection, but this
feature is to prevent from trying to deliver
in the first place.
This cache includes group members for the
sender. So if a person sends to a DL, this
cache tracks membership of that person
so that if restrictions apply to any sub DL,
it doesn’t have to be looked up again.
You would want to make this larger if you
notice a lot of Active Directory queries
for messages to large DLs with complex
delivery restrictions.
Message Routing in Exchange 2010
Verifying Configuration Using the Routing Log Viewer
The Routing Log Viewer is one of the most important tools to understand how Exchange is
interpreting your configuration changes in means of Active Directory sites, Active Directory
site links, and so on. You use the Routing Log Viewer to open a local Routing Table log file
located on your Hub or Edge Transport servers.
The Routing Log Viewer only shows you the routing table of a single Hub Transport
server. This means you always need to connect to the Hub Transport server that causes
the message routing problem to investigate its local routing table. If you are connected to
a different transport server, you might not be able to detect the issue!
After opening a routing table log file (normally you open the latest one available), the
routing table is organized into four tabs: Active Directory Sites (and Routing Groups if you
have Exchange 2003 servers in your organization), Servers, Send Connectors, and Address
If you want to read more about the Routing Log Viewer and how to use it, the TechNet
article “Viewing the Routing Table Log” is available at
On this tab you can make sure that your Exchange servers belong to the correct Active
Directory site, and also determine whether any Hub sites are identified incorrectly. You can
also see the least cost to each of the other sites by identifying the Total Active Directory
cost item, as shown in Figure 5-9. You do not see the difference between Active Directory
costs and Exchange costs assigned to an Active Directory site link, but the routing table just
provides you with the cost information used by the Hub Transport server.
FIGURE 5-9 Viewing Active Directory sites in Routing Log Viewer
Routing and Transport
The Servers tab provides an overview of all Exchange servers in your Exchange organization.
You get an overview of the roles installed, the routing cost to reach the server, any MDB
databases (mailbox databases) available on this server, and its Legacy DN.
This tab provides you with an overview of send connectors that are available for this specific
Active Directory site, as shown in Figure 5-10. It includes the address space, information about
the proximity of the connector, whether the message is delivered using a smart host or DNS,
whether it is a scoped connector, and the message size restriction set on it.
Scoped connectors are only available in the local Active Directory site—thus the
address space of a scoped connector does not show up in another Active Directory site’s
Send Connector tab.
FIGURE 5-10 Viewing Send Connectors in Routing Log Viewer
The Address Space tab provides a hierarchical list including all address spaces available for
this Hub Transport server. You can expand the list until you find the Send connector that
serves the address space.
Message Routing in Exchange 2010
This tab is especially important in organizations that have many address spaces configured,
which might also have a lot of connectors. In this situation it is maybe easier to search
for a Send connector by looking through the available address spaces on this tab than to
examine the connectors listed on the Send Connector tab.
Planning Message Routing to the Organization Perimeter
In Exchange Server 2010, connectors are classified in the following ways:
Send connectors
Receive connectors
Foreign connectors
Delivery Agent connectors
These types of connectors can be configured on Hub Transport and Edge Transport
servers. Connectors can be configured using the Exchange Management Console, but many
more details are available when using the Exchange Management Shell.
Send and Receive connectors always use SMTP as their message protocol. Foreign or
Delivery Agent connectors use other message protocols, such as X.400, to transmit messages.
Configuring Send Connectors
A Send connector is a connector that transmits a message to the Exchange organization
perimeter using SMTP as the communication protocol. Thus by default it sends the message
using TCP port 25. You use Send connectors to configure how your messages leave the
organization. Send connectors allow you to do the following:
Set one or more source Hub Transport server(s) that the connector uses to deliver
Configure one or more dedicated address space(s) for the connector.
Decide where to route the messages (by using a smart host or just using DNS MX
record resolution).
Here’s what you should consider when planning Send connectors:
Hub Transport servers communicate automatically with each other—you do not need
Send connectors for internal communication. Nor should you try to configure internal
routing with send connectors because you could cause internal routing issues.
If you don’t use Edge Transport servers as Internet smart-relay hosts, you should
include a Send connector with the SMTP:* address space pointing to the network
connection point to the Internet or to a smart host that is able to send messages to the
Routing and Transport
For organizational internal message re-routing meaning where you have other
SMTP systems inside your company, you should add the address spaces to the Send
connectors. Whether you create one connector for many partners or one connector
per partner depends on whether you want to manage the connectors using DNS
with MX-records or using smart hosts. Also consider the management aspect when
deciding on one or more connectors.
You can put a scope on the Send connector to prevent other Active Directory sites
from using it. However, don’t forget that a connector with scoped address space
should not be located in the same site as the alternate least-cost route connector with
non-scoped address space. Thus you also should not configure a scoped address space
at Hub sites.
Scoping Send Connectors Correctly
Todd Luttinen
Principal Program Manager, Microsoft Corp, Redmond
f you put a scope (an assigned address space) on a Send or Foreign connector, you
prevent Hub Transport servers located in other Active Directory sites from seeing
it in their local routing tables. Because these transport servers will not see the
connector and its associated scoped address space, they are prevented from using
the scoped address space and associated connector to compute least-cost routes for
external recipient delivery.
However, you need to consider that the routing calculation is done not only at the
source Hub Transport, but also at every Hub Transport the message is forwarded to.
It will be checked against the local routing table of each Hub Transport server to find
the optimum connector based on least cost and maximum message size. If one Hub
Transport along the way includes a scoped connector that is more suitable for the
message to follow, it will use it.
For example, assume you’re in the Site-Fresno of the Litware Exchange organization.
The Site-Fresno has two Send connectors: one to the Internet with SMTP:*, and one
connector with a Scope to Partners with You now send a message
from Site-Berlin to the Internet, which automatically uses Site-Fresno to forward
the message to the Internet. The message will see the scoped Send connector and
use the Partners connector to deliver the message. The best way to prevent this
from happening is not to use scoped Send connectors in Hub sites or sites where all
messages are sent through.
Message Routing in Exchange 2010
If you consider using Send connectors that deliver messages to the Internet, you have the
following two possibilities to resolve the domains used in recipient addresses:
Using a smart host to deliver the messages to the Internet (the most common scenario
when you do not use Edge Transport servers in your organization).
Using DNS MX records to resolve Internet addresses on your own when using an Edge
Transport server.
Microsoft does not recommend connecting a Hub Transport server directly
to the Internet. Thus it is best practice to install a smart host between the Internet and your
Exchange organization.
When using DNS to resolve message addresses, Exchange queries an external DNS to find
the DNS records required for message delivery. The DNS servers are queried for the following
Mail exchange (MX) records The MX record contains one or more fully qualified
domain names (FQDNs) of the server that are responsible for accepting messages for
the domain and a preference value. The lowest preference value is always selected
first. To optimize fault tolerance, most organizations use multiple messaging servers
and multiple MX records that have different preference values. If one server fails, the
other is used because of the higher preference value.
Address (A) records Every server that has an MX record also has an A record
assigned to it. The A record includes the IP address of the server.
Configuring a Failover Scenario with MX Records
Ross Smith IV
Senior Program Manager, Exchange Server Product Group, Microsoft Corporation
here are many different ways to deploy MX records for controlling inbound
Internet mail flow. To frame this discussion, consider a customer who has two
physical locations with an ideal configuration that ensures both locations are used
in some fashion for internal and external mail routing. As a result, there are three
One physical location is considered primary and the other physical location is
a backup.
Both physical locations are utilized for mail flow.
Use a single MX record.
Routing and Transport
For the first possibility, the DNS configuration can be set as follows:
MX preference = 10,
mail exchanger =
MX preference = 20,
mail exchanger =
With this mechanism, both MX records are provided to the sending SMTP system,
but the lowest-cost MX record is utilized first. When the TCP/IP address of the
host is resolved, the DNS name server rotates the address values that it returns
(via a round-robin mechanism). In this way, DNS guarantees
hosts are cycled through and used equally for receiving inbound mail. Using this
approach means that you take control for cycling through the mail systems: you
are not at the mercy of the sender’s SMTP implementation and thereby balancing
mail volume efficiency across all of the Edge Transport servers. The first MX record
is associated with SMTP servers in one data center, whereas the second, higher-cost
MX record is associated with SMTP servers in the second data center.
This configuration can also be invoked for load-balancing data across physical
locations. For example, can be associated to IP addresses in
primary datacenter and IP addresses in second datacenter. The same can be done for The end result in this scenario is that only half of the existing
Edge Transport servers are used at any given time, with an equal distribution of
messages between the two data centers.
Another solution for load balancing across physical locations is to utilize two equal
cost MX records:
MX preference = 10,
mail exchanger =
MX preference = 10,
mail exchanger =
Message Routing in Exchange 2010
The difference here is that is associated to IP addresses in
one datacenter, whereas is associated to IP addresses in the
other data center. Although this solution cannot guarantee an equal distribution of
messages between datacenters, it can guarantee an equal distribution of messages
for a particular MX record.
The third possibility is to utilize a single MX record:
MX preference = 10,
mail exchanger =
With this configuration, all Edge Transport servers in both datacenters are
associated to the MX record. This configuration utilizes all SMTP servers and
ensures an equal distribution of messages between all of the SMTP servers in both
datacenters. If the customer’s goal is to have mail flow come into either datacenter,
this is the best configuration option. However, if the customer’s goal is to ensure
that mail flow is controlled in terms of datacenter usage, the first scenario is the
best configuration option.
If you implement Edge Transport servers, you do not need to create additional Send
connectors by default because they are all created using a default configuration. However, as
in the Fabrikam scenario that uses smart host servers to send messages to the Internet, you
need to create a Send connector so that your Exchange servers are able to send messages to
the Internet.
For example, assume you’re the Fabrikam administrator and you need to create a Send
connector to your smart host including the SMTP:* address space. The connector needs to be
configured on the Hub Transport server Fresno-HT01. Here’s the cmdlet that would create the
Send connector to the smart host:
New-SendConnector -Name 'To Internet' -Usage 'Internet' -AddressSpaces 'SMTP:*;1'
-IsScopedConnector $false -DNSRoutingEnabled $false -SmartHosts 'smarthost' -SmartHostAuthMechanism 'None' -UseExternalDNSServersEnabled $false
-SourceTransportServers 'FRESNO-HT01'
Fabrikam might create additional Send connectors for the following reasons:
They have a dedicated Partner WAN link that they would like to use to send messages
between both companies.
They have an internal SMTP server that shares the same address space, so they forward
all messages not resolved by the Exchange organization to that SMTP server.
Routing and Transport
Many parameters are available to configure Send connectors. Table 5-15 provides
an overview of the most important parameters, what they are used for, and when you
need to consider changing them.
TABLE 5-15 Set-SendConnector Parameters
Address space(s) are
processed by this
To configure target
Address Spaces (for
example, “SMTP:*”
to send all messages
through it).
Defines authentication
credentials (user name
and password).
When your target
connector requires
Defines comments for
this connector.
To provide additional
details regarding
the purpose of the
For Exchange 2003
support, includes
connected routing groups.
Cannot be changed.
Times when to
disconnect an idle
Can be changed to
reduce the amount of
idle connections.
Specifies that the
connector will use the
local DNS Server to
resolve the message.
If you don’t have a smart
host to relay messages,
you need to use this
Configures Domain
Security using TLS on
this connector.
Enable if you want to
support Domain Security
to partners or others.
Enables or disables this
Only if you want to
disable the connector.
Remember, disabling
connectors causes issues
with Exchange 2003.
You can configure the
server to respond to
SMTP connections with
HELO rather than EHLO.
You need to change this
if your target SMTP
server requires the HELO
command to be sent.
Message Routing in Exchange 2010
Specifies the FQDN that
will be provided after
If the target server
requires a specific
response after EHLO,
you can change
it here.
For Exchange 2003
support, includes
Microsoft MTA.
Cannot be changed.
Transport Server on
which the connector
was created.
Cannot be changed.
GUID of connector.
Cannot be changed.
Configures whether
the connector uses TLS
if offered.
Change it only if you
want to disable TLS for
this connector.
Defines the scope of
this connector.
When changed, the
connector can only be
used by Hub Transport
servers in the same site.
Specifies SMTP as
Cannot be changed.
Forces all messages
received by a specified
Receive connector to
be sent over this
Useful if you want to
forward all messages for
inspection, such as to
a third-party anti-spam
Maximum message size
the connector can send.
Configure a specific
message size.
Name of the connector.
Change the name.
Port number to
If the send connector
uses a port other than
port 25.
Configures the
logging level for SMTP.
Enable verbose logging
for troubleshooting
connector issues.
Configures that
communication must be
encrypted using TLS.
Change this only if
you’re sure that all
target servers
support TLS.
Routing and Transport
Defines the authentication
mechanism when using
a smart host.
If the smart host requires
specific authentication,
this option needs to be
configured accordingly.
Defines IP address, MX
records, or A record(s) of
any smart host(s) used.
Configure a smart host
if you want to forward
all messages to the
specified server(s).
Includes the SmartHosts
parameter as a string.
Cannot be changed.
Maximum messages this
connector can send per
If the target connector
is configured to receive
more messages, it can
be changed accordingly.
Specifies a specific IP
address that will be shown
to the target connector.
If your local server has
multiple IP addresses
and the target server
requires one specific
IP address, such as for
Routing group the
Cannot be changed.
connector belongs to. Only
used for backward
compatibility with
Exchange 2003.
Specifies the names of the
Transport servers that can
use this connector.
For redundancy, you
should always add all
Hub Transport servers
that can use it.
Uses DNS server(s) that
were specified in
If this connector needs
to use another DNS
server that is configured
Configuring Receive Connectors
To receive inbound SMTP messages from external domains, you need a Receive connector in
Exchange 2010. This connector acts as an inbound connection point that you can configure
to accept connections based on IP address ranges and port numbers. You can configure
a Receive connector on a per-server scope only. Thus, if you want to have many servers
receive messages, you need to configure one connector for every server.
Message Routing in Exchange 2010
Receive connectors have configuration limits that you can set, such as number of active
connection, maximum message size, or maximum recipients per message. You also can set
the type of authentication required to send a message.
By default two Receive connectors are created on every Hub Transport server that are
almost identical, but with one important difference: You configure the Client <servername>
Receive connector to listen on port 587 rather than on port 25. As described in RFC 2476,
port 587 has been proposed for use only for message submission from e-mail clients that
require message relay.
A Receive connector by default only accepts e-mail domains that are defined
in Accepted Domains that you can list using the Get-AcceptedDomain cmdlet. All other
domains are considered Message Relaying and need additional permissions to be
What does this have to do with planning? Well, you should configure Receive connectors
at every Hub Transport server serving an external inbound connection. Also, you should have
dedicated Receive connectors for your applications that want to send messages so that you
understand how many applications send messages to your system.
Which Receive connectors do you need for a specific environment like the Fabrikam
Scenario? As mentioned, Fabrikam has Apple Macintosh clients that use IMAP4 to receive
their messages from the CAS server. However, POP3 and IMAP4 need to use SMTP to send
messages. They also use a smart host to send and receive messages from the Internet.
To ease management, you create new Receive connectors (instead of using the default
connectors) enforcing authentication as well as encrypted client-to-server communication
using TLS. For your sample scenario the following Receive connectors should be created:
Receive connector to receive messages from Internet smart host
Receive connector to receive messages from IMAP4 clients using TLS
You can create an example Receive connector configuration for the IP range of
(Subnet, enforcing TLS encryption, and only allowing Exchange mailbox users
and Exchange servers to use it on the local Exchange server by using the following cmdlet:
New-ReceiveConnector -Name "Client SMTP TLS" -Bindings "" -AuthMechanism
"Tls, BasicAuth, BasicAuthRequireTLS, ExchangeServer" -PermissionGroups "ExchangeUsers,
ExchangeServers" -RemoteIPRanges
The most important task after creating a Receive connector is to test its
functionality. You can use Telnet <servername> 25 to connect to the Receive connector
or use a client to check it. Remember that the Telnet Client is now a Windows Server 2008
feature that is not installed by default.
Routing and Transport
Additional reasons to create Receive connectors are as follows:
To receive messages from an Internet smart host (if you do not use Edge Transport
servers to receive messages from the Internet)
If you need to turn off user authentication for specific clients based on IP address
To allow relaying of messages accepted from SMTP servers
For using a dedicated Receive connector for Domain Security on Edge Transport
Configuring Relaying in Exchange Server 2010
Christian Schindler
Senior Consultant, NTx BackOffice Consulting Group, Austria
n previous versions of Exchange Server you enabled relaying by simply activating
a check box on the Properties page of an SMTP Virtual Server and adding IP
Addresses to a list. In Exchange Server 2007 and 2010 this has changed a bit.
First, the SMTP Virtual Server no longer exists—the replacement is a Receive
connector. Second, there’s no check box to simply activate relaying—we have to
use permissions in Active Directory to allow for relaying. However, we still need to
specify which IP Addresses are allowed to relay.
To enable Relaying on an Exchange Server 2010 Hub Transport Server, you create
a new Receive connector. Then you specify the server’s IP addresses that are allowed
to relay by configuring the RemoteIPRanges parameter of the Receive connector.
As a final step, you need to set permissions on the Send connector to grant
Anonymous the right to relay. This can be done either via ADSIEDIT or by using the
following Windows PowerShell command:
Get-ReceiveConnector <Name of Connector> | Add-ADPermission -User "NT
AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-AnyRecipient"
During a migration from previous version of Exchange, you need to create relaying
connectors with the same settings as on the original servers. Getting the list of
allowed server IP addresses is particularly important. When you have a large list,
it is crucial to automate this step to avoid human errors. This can easily be done
by using the ExIpSecurity.exe Tool, which can be downloaded from the Microsoft
Download Center. It allows you to export the list of allowed IP addresses to a file.
The file can easily be used in a Windows PowerShell script to create the necessary
Receive connectors in Exchange Server 2010.
Message Routing in Exchange 2010
A linked connector is a Receive connector that is linked to a Send connector. For linked
connectors, the regular routing logic that is based on the destination domain is overridden.
All messages that are received by the Receive connector are forwarded to the linked Send
You can see an example of a linked connector in the Fabrikam scenario: they want to
outsource their anti-spam and antivirus service. They thus create a linked connector at the
Internet message entry point in their Exchange organization and forward all messages to
a third-party service provider for scanning. Then they receive the message back from the
service provider using a dedicated Receive connector that is no longer linked.
The following list describes the requirements that you must meet to create linked
Only one Receive connector can be linked to one Send connector.
The Receive connector must exist before it can be linked to a Send connector.
A linked Send connector must route messages to a smart host.
You can only link a Receive connector to an existing Send connector by using the
LinkedReceiveConnector parameter in the Set-SendConnector cmdlet.
Table 5-16 provides an overview of the most important parameters for Receive connectors.
However, many more parameters can be configured on Receive connectors. You do not need
to know them by heart, but should remember what options are available if you need them.
TABLE 5-16 Set-ReceiveConnector Parameters
Defines the advertised and
accepted authentication
If you want to enforce
TLS encryption or a
specific Authentication
type, you need to
configure it here.
The Banner parameter
specifies an override to the
default SMTP 220 banner.
If you like to respond in
a customized way to
requests, this can be
Specifies whether the
keyword is advertised
and is available for use.
Routing and Transport
Specifies the local IP
and port number the
connector listens to.
Chunking enables large
message bodies to be
relayed by the remote
server to the Receive
connector in multiple,
smaller chunks.
Specifies whether the
delivery status notification
(DSN) EHLO keyword is
advertised in the EHLO
response to the remote
server and is available
for use.
Enables or disables Domain
Security (also known as
mutual TLS).
Domain Security is
normally only enabled on
Edge Transport servers
to securely communicate
over the Internet.
Enables or disables
8-bit MIME.
MIME 8-bit should only
be disabled if you face
issues when receiving
binary data, such as
Enables or disables
enhanced Status Codes.
Enables the Receive
connector to accept long
X.400 e-mail addresses.
Specifies whether to enable
the Originator Requested
Alternate Recipient (ORAR).
Defines whether standard
TLS encryption for
incoming connections is
If you change the
bindings to a different
port, make sure that all
sending servers also use
the same port.
If you use WOC devices
to optimize WAN links,
you want to change the
default setting to turn
off TLS.
Message Routing in Exchange 2010
Defines whether the SMTP
server name, port number,
and authentication settings
are displayed in the
Outlook Web App About
page, which is accessed
from the Help menu.
Enables or disables this
Specifies the maximum
time that a connection can
remain open, even if the
connection is actively
transmitting data.
If you have SMTP clients
that transmit large
amounts of data over
a slow link, consider
increasing this
Defines the maximum
amount of idle time before
a connection is closed.
Change this setting if
you want to fine-tune
message throttling
Defines the maximum
number of messages that
can be sent by a single
client IP address per
Change this setting if
you want to fine-tune
message throttling
Specifies how the message
submission rate is
calculated (None, IPAddress,
User, All).
Defines the maximum
number of inbound
connections that this
Receive connector serves
at the same time.
Change this setting if
you want to fine-tune
message throttling
Defines the maximum
number of inbound
connections that this
Receive connector serves
at the same time from
a single IP address.
Change this setting if
you want to fine-tune
message throttling
Routing and Transport
Especially in CAS arrays
you should enable this
to be able to identify the CAS server the
client is connected to.
Specifies in bytes the
maximum size of the
SMTP message header.
Specifies the maximum
number of hops that a
message can take before
the message is rejected
by the Receive
Specifies the maximum
number of local hops
(for example, internal
Exchange servers) that a
message can take before
the message is rejected by
the connector.
Number of logon failures
that the Receive connector
retries before closing the
Specifies the maximum
size of a message.
Specifies the maximum
number of SMTP
protocol errors before
closing the connection.
Defines how many
recipients a single
message can address.
name of connector.
Defines the groups or
roles that can submit
messages to the Receive
connector: ExchangeUsers,
and so on.
For large organizations,
you might need to
increase the value if you
configure many Hub
sites for Exchange,.
Change this setting if
you want to fine-tune
message throttling
Message Routing in Exchange 2010
Enables or disables
Pipelining in SMTP to
send requests without
awaiting a response.
Specifies whether to
enable protocol logging
for the specified Receive
Defines the remote IP
addresses that can use
this connector.
Specifies whether the
remote computer must
provide a domain
name in the EHLO
Configured if a session
requires TLS encryption.
Specifies how to control
the advertisement of the
Generic Security Services
application programming
interface (GSSAPI)
authentication method
when Integrated
Windows authentication
is enabled on this
Specifies whether the SIZE
SMTP extension is
Routing and Transport
If you have trouble
with the connector,
enable Verbose logging
to see the full SMTP
communication in the
log directory.
Set this to $true if you
want to make sure the
communication is
You can change this
on Edge Transport
servers to advertise
the maximum message
size that is allowed in
EHLO banner.
Specifies the period of time
to delay an SMTP response
to a remote server that
Exchange determines may
be abusing the connection.
Authenticated connections
are never delayed in this
Specifies the time
a Transport Server
waits when sending a
message to a server that
doesn’t support shadow
redundancy before sending
the acknowledgment.
Change this setting if
you want to fine-tune
message throttling
options for anonymous
Configuring Delivery Agent Connectors
A delivery agent connector is similar to the Foreign connector in that it is used to route
messages to foreign systems that don’t use the SMTP protocol, such as an X.400-based
messaging system that does not have an SMTP connector available. When a message
is routed to a delivery agent connector, the associated agent performs content conversion
and message delivery.
The advantage of using the delivery agent connector is that the agent already performs
content conversation and message delivery—thus there is no need to store messages on the
file system in a Drop or Pickup directory as required by the Foreign connector.
The delivery agent functions as follows:
It establishes a connection to the foreign system.
It retrieves messages from the Hub Transport’s remote delivery queues.
It delivers the message to the foreign system and receives an acknowledgment for
each successful delivery.
It retrieves waiting messages from the foreign system.
In comparison to the Foreign connector, where you place the message only in a drop
directory and wait until it is processed, a delivery agent connector acknowledges the message
delivery to the foreign system and thus allows service level agreement (SLA) analysis as you
can track message latency to the foreign system. You also can use Exchange’s Queue Viewer
to verify message delivery, which is not the case with Foreign connectors.
Message Routing in Exchange 2010
While the Foreign connector architecture remains in Microsoft Exchange Server
2010, Microsoft recommends using delivery agents for routing messages to non-SMTP
systems whenever possible.
Exchange Server 2010 by default only comes with one Delivery Agent Connector: the Text
Messaging Delivery Agent connector. This connector is used to route messages to mobile
phones using the Address Space MOBILE:*, as shown in Figure 5-11.
FIGURE 5-11 Default Delivery Agent connectors
Microsoft’s intention is to replace connectors with other non-SMTP mail systems that
were written with the old Exchange 2003 SDK (Foreign connectors) with new Delivery Agent
connectors written using the Exchange 2010 SDK. Therefore, you would buy a new Delivery
Agent connector for a foreign e-mail system such as Lotus Notes or Novell GroupWise from
a third-party developer or you’d build your own connector if you had the time, patience,
and expertise.
You use the Set-DeliveryAgentConnector cmdlet to configure the connector; you get
information about the connector’s configuration using the Get-DeliveryAgentConnector cmdlet.
Configuring Foreign Connectors
A Foreign connector is a connector that does not use the SMTP protocol for communication
and was implemented with Exchange Server 2003 SDK. Even though it is not the
recommended way to connect Exchange to a foreign system because Exchange 2010
implements Delivery Agent connectors to handle messages to foreign systems in a more
sophisticated way, it still exists and can be used for existing third-party connectors.
To be able to communicate with third-party systems, the Foreign connector uses a Drop
directory to send messages to the foreign gateway servers. Foreign gateway servers can
send messages to Exchange Server 2010 by using the Replay directory found on every Hub
Transport server in <Exchange_Installation_Path>\TransportRoles\Replay.
Every Foreign connector has an address space assigned to it that includes the following
Connector Scope Hub Transport servers that can use the connector
AddressSpaceType For example, FAX or X.400
AddressSpace A valid address space for the AddressSpaceType
AddressSpaceCost Routing costs
Routing and Transport
Planning for Foreign connectors is a key task when doing an Exchange Server 2010 design.
You should consider the following in your plan:
Plan for fault tolerance when implementing Foreign connectors; make sure the Drop
directory is available.
Make sure the third-party connector fully supports Exchange Server 2010 before you
move it over to the Exchange server, especially if you are in an environment where
Exchange 2003 still exists. Alternatively, you can simply keep an Exchange 2003 server
in place to host the old connector until you can either replace it with a new Delivery
Agent connector or work out how to route messages to the other e-mail system
with SMTP.
Planning and Configuring Your SMTP Namespace
Another important aspect is to plan and configure an SMTP namespace. The SMTP message
protocol is the internal message protocol of Exchange 2010. Thus, you identify an Exchange
organization by its primary SMTP namespace.
The SMTP namespace is configured in the Internet using one DNS MX record per SMTP
domain that points to your Exchange organization. You need to make sure Exchange
understands what to do with the SMTP namespaces that enter your Exchange organization.
Accepted Domains
The accepted domain property specifies one or more SMTP domain names for which the
Exchange server receives mail. If an SMTP Receive connector on the Exchange Server 2010
Hub Transport server receives a message that is addressed to a domain that is not on the
accepted domain list, it rejects the message and sends a relaying denied response.
When you create a new accepted domain, you have three options for the domain type you
can create:
Authoritative Domain Select this option if every e-mail addresses for this domain
name exists in Active Directory (as mailbox, contact, and so on). If a message is
received that has a recipient e-mail address that is not in the Active Directory, an NDR
will be created for that message. The Contoso scenario, where you only use Exchange
as the messaging system, is an example where you define all domains as authoritative.
Internal Relay Domain This option is to configure a shared address space with
one or more messaging systems. If the e-mail address does not exist in your Active
Directory, Exchange will forward the message using a Send connector. You need at
least one Send connector with the internal relay domain configured as address space
so that the Hub Transport servers will send the message that are not found in your
Exchange organization to the correct target SMTP server. For example, you would use
this option during a migration in which your legacy messaging system and your new
messaging system share the same e-mail addresses.
External Relay Domain Select this option to relay messages to an SMTP server
outside of the Exchange organization or the organization’s network. An Edge Transport
server is responsible for routing the messages received to the target SMTP server.
Message Routing in Exchange 2010
Your organization is therefore responsible for the DNS MX record of this company
and forwards every message received to the target server. It requires a Send connector
from the Edge Transport servers to the external relay domain’s SMTP server that
includes the external relay domain as address space.
To configure accepted domains using the Exchange Management Shell, use the
New-AcceptedDomain or Set-AcceptedDomain cmdlets. This allows you to easily create or
modify many domains with a single operation.
Remote Domains
Remote domains define SMTP domains that are external to your Exchange organization. You
can create remote domain entries to define the settings for message transfer between the
Exchange Server 2010 organization and domains outside your AD DS forest.
When you create a remote domain entry, you control the types of messages that are sent
to that domain. You can apply message-format policies and acceptable character sets for
the messages that are sent from your organization’s users to the remote domain as well as
determine out-of-office message settings.
The out-of-office message settings control the messages that are sent to recipients in the
remote domain. The types of out-of-office messages that are available in your organization
depend on both the Microsoft Office Outlook client version and the Exchange Server version
on which the user’s mailbox is located.
An out-of-office message is set on the Outlook client but is sent by the Exchange server.
Exchange Server 2010 supports three out-of-office message classifications: external, internal,
and legacy, as shown in Figure 5-12.
FIGURE 5-12 Out-of-office settings for remote domains
Routing and Transport
You can configure multiple message format options to specify message delivery
and formatting policies for the messages that are sent to recipients in the remote domain.
The first set of options on the Message Format tab apply restrictions to the types of
messages that can be sent to the remote domain, how the sender’s name displays to the
recipient, and the column width for message text. These options include:
Allow automatic replies.
Allow automatic forward.
Allow delivery reports.
Allow non-delivery reports.
Display sender’s name on messages.
Use message text line-wrap at column.
Use the Exchange rich-text format settings to determine whether e-mail messages from
your organization to the remote domain are sent by using Exchange Rich Text Format (RTF).
Remember that the Microsoft RTF format is not automatically supported by every LINUX or
UNIX SMTP server; thus if the recipients of messages from your organization complain about
weird attachments or missing attachments, you should try to disable RTF for that domain.
The Characters Sets options let you select a MIME character set and a non-MIME character
set to use when you send messages to a remote domain.
TargetAddress Routing
Another way to modify message routing is to add a SMTP address to the TargetAddress
attribute of a mail-enabled user account object or a contact object. After the attribute is
added, the object is available in the Global Address List (GAL) and also can be addressed by
using its primary SMTP address. Messages sent to the object will be automatically forwarded
to the SMTP address defined in TargetAddress.
The first time I used this technology was back in the old Exchange 5.5 days, with an
Exchange migration product called Quest Exchange Migration Wizard. This tool created one
contact for every mailbox and used the TargetAddress attribute to forward messages to the
target environment.
The TargetAddress attribute is defined on a per-object level; thus you can define which
objects are redirected and which are not. You should consider the following if you’re planning
to use TargetAddress routing in your environment:
You need to configure a Send connector that includes the target domain as address
Message Routing in Exchange 2010
To share one address space, create an Internal Relay Domain for it. The internal relay
domain should be the primary SMTP address of the objects. This is required to have
users in both messaging systems (source and target) be able to address the contacts
or mailboxes in both system by using their primary SMTP address.
You need to create one contact or mail-enabled user account per e-mail address to be
capable of forwarding it. The TargetAddress attribute will include a dedicated SMTP
address for the target messaging system.
Remember that as soon as you mailbox-enable a user account, the TargetAddress
attribute will be removed and any message forwarding will be stopped.
Additional Resources
Understanding the Pickup and Replay Directories:
Microsoft Active Directory Topology Diagrammer:
Viewing the Routing Table Log:
Understanding Message Throttling:
Understanding Back Pressure:
Understanding Transport Agents:
Routing and Transport
Mailbox Services
Introduction to Exchange Server 2010 Mailbox Services 259
Exchange Mailbox Services Architecture
What Is New in Exchange Server 2010 265
Exchange Mailbox Services Configuration
he primary function of the Mailbox role in Exchange Server 2010 is to serve
and store mailbox data. In this version, advances have been made to the Mailbox
role to increase the sophistication of high-availability options while reducing the
non-core services by moving them to other Exchange roles. Without a solid core
database, the other services are irrelevant. Although rumors have circulated since the
debut of Exchange 2000 Server about replacing the Exchange ESE (JET Blue) database
with a Microsoft SQL Server–based database, the ESE database is still in the product,
performing better and providing unique high-availability solutions that other messaging
and relational databases are not able to provide. This chapter covers the basic Mailbox
server architecture, and new features and functionality in the Mailbox server role, and
then applies some real-world administrative guidelines for configuration and maintenance.
Introduction to Exchange Server 2010
Mailbox Services
The Exchange server product has slowly evolved to be much more than simple e-mail
services; however, the heart of the product still lives on in the Mailbox role. Microsoft’s
original mail product, Microsoft Mail, was little more than message items stored on disk
and some external applications that acted as message transport agents (MTAs) that were
used to move mail around. As electronic messaging became more important to businesses,
it was clear that the architecture of Microsoft Mail would not scale to meet growing
business needs; it was then replaced with the Exchange Server product. Version 4.0 was
the first version of Exchange Server, coming to the market in 1996 to provide improved
scalability and improve the connectivity of the e-mail system to other systems.
Exchange Server 4.0 did provide a more scalable product, with a unified address
book and a way to interface with a variety of e-mail systems. As Exchange Server 5.0
and Exchange Server 5.5 came to market, additional connectors were made available
to embrace emerging Internet standards like SMTP. Also added in Exchange Server 5.5 was
a Web-based client originally named the Exchange Web Client and then renamed Outlook
Web Access (now renamed Outlook Web App in Exchange Server 2010).
With the introduction of Exchange 2000 Server, Outlook Web Access also ran not only on the
same server, but the core functionality ran in the Information Store (store.exe), which was the
same process that handled the database functionality. Exchange 2000 Server also introduced
the streaming database file (STM) to store the content of messages that were not in native MAPI
format. When these messages were accessed by a MAPI client, the data would be promoted
into the ESE Exchange database; however, if the message was accessed with an IMAP or POP3
client no conversion would happen. The intent was to reduce the amount of conversions that
needed to happen and thereby reduce the overall resources required on the Exchange Server.
The streaming database file was discontinued starting with Exchange Server 2007.
Beginning with Exchange Server 2007, the development team began peeling out many of
these functions from the database to reduce the bloat and sensitivity to any code changes.
For example, in Exchange 2007 the Outlook Web Access (OWA) was completely rewritten.
OWA no longer used the Information Store to render the HTML for OWA. Also, the Exchange
Server 2007 introduced server roles, allowing separation of functionality onto different
servers, only needing to run the required roles on specific servers. Again in Exchange 2010
additional functionality was removed from the database and moved to other roles. For
example, in Exchange Server 2010, MAPI-based client connectivity has been moved from
the Mailbox role to the Client Access Server role. Having fewer non-core functions running
within the information store process has improved performance and stability and added
in additional high-availability functionality.
Exchange Mailbox Services Architecture
A database schema is the definition of how the data is stored in the database file. As
shown in Table 6-1, in all earlier versions of Exchange Server, each database has a mailbox,
folder, message, and attachment table. These tables are used to store all information for all
mailboxes in the database. This provides the ability to only store a message and attachment
once for each of the mailboxes in the database. The previous database schema also includes
a table for each folder to store the item contents of each folder.
TABLE 6-1 Exchange Server 2007 Table Structure
Terry: Sent Items Terry: Message 42
Terry: Word.docx
Terry: Inbox: MH1
Ankur: Unread
Ankur: Message 26
Ankur: Manual.pdf
Terry: Inbox: MH2
Joel: Inbox
Joel: Message 144
Joel: Pricing.xlsx
Terry: Inbox: MH3
Mailbox Services
Single instance storage no longer provides the space savings that it did when it was first
introduced, because of a number of factors. The architecture used to support single instance
storage also no longer provides adequate performance for SATA-based storage (this will
be covered in more detail later in this chapter). The database structure in Exchange Server
2010, shown in Table 6-2, was re-architected to now only have one per database table—the
mailbox table. All of the folders, message headers, and message bodies are stored in a table
for each mailbox. There is also a table for each view, which stores the contents and status of
each message included in each view.
TABLE 6-2 Exchange Server 2010 Table Structure
KC: Sent Items
KC: Message 42
KC: Word.docx
KC: Unread
KC: Message 26
KC: Manual.pdf
KC: Inbox
KC: Message 144
KC: Pricing.xlsx
This new database structure allows data to be stored contiguously and to keep frequently
accessed data located more closely together, as can be seen in Figure 6-1. When the data is
contiguous, the amount of I/O that is required is reduced.
B+ Tree
Fewer, larger sized, and sequential I/O
FIGURE 6-1 Contiguous database structure
Database Files
The mailbox data is stored in the Extensible Storage Engine (ESE) database, which is
represented in a number of files that are stored on the Mailbox Server. Each database is
represented by a single instance of the ESE instance and shares a single set of transaction
log files. Whenever a transaction occurs, ESE first records the transaction in memory to the
Exchange Mailbox Services Architecture
log buffers and then to a transaction log. The transaction logs contain a history of all the
bit-level changes that are committed to the database. In the default database configuration,
transaction logs will continue to build up until they are truncated.
Truncation, or deletion of the committed transaction logs, usually occurs when a backup
of the database is completed. However, if the database is configured for circular logging, after
the transaction logs are committed into the database, the transaction logs are replaced with
new transaction logs. Therefore, the most current state of an Exchange service is represented
by the database file plus the current log files. Checkpoint files are used to keep track of which
transaction logs have been committed to the database. Checkpoint files are named Enn.chk
and normally reside in the same directories as the transaction log files.
The basic database files for a database named Dallas-EX01-MB04 are shown in Figure 6-2.
FIGURE 6-2 ESE files
Database Name.edb (Dallas-EX01-MB04.edb)
This file is the B-tree database file. This is where all of the data is stored for mailboxes
and in the case of a public folder database where public folder data is stored.
Enn.chk (E02.chk)
The checkpoint file contains a record of the committed transaction logs and which
logs are yet to be committed. The checkpoint file, as well as many of the other files, is
named with the log file prefix, such as E00 for the first database on a server, E01 for the
second database, and so on.
Enn.log (E02.log)
This is the current transaction log file for the first database. Data is still being written
into this file. When the data in this log reaches 1,024 KB or if the server is idle for
a period of time, it will be renamed to the next sequential number for the database.
A new Exx.log file will then be created, and transactions will be written to it until it
is full.
Mailbox Services
Ennres00001.jrs and Ennres00002.jrs (E02res00001.jrs and E02res00002.jrs)
These files are used to reserve emergency storage if the transaction log volume
becomes full. In the event that the volume becomes full, these files are deleted
to make room for the transactions being processed to be written to disk, and the
databases are dismounted. By having two reserved transaction logs, Exchange can
reduce the likelihood that transactions will be lost during this process. These files are
always 1,024 KB in size.
Ennhhhhhhhh.log (E0200000A0.log through E0200000A5.log)
These files are older transaction log files and are named with the log prefix, such
as E01, followed by an eight-character hexadecimal number. Thus the file named
E0100000001.log is the first log file for the second database on the server. The
transaction logs are named with the numbers 1 through 0 and the letters A through
F as are used in hexadecimal numbering system. These files will always be 1,024 KB in
size. These files are kept until they are truncated—which is done after a successful full
backup of the database—or are overwritten after they are committed when circular
logging is enabled.
This file is a temporary workspace for processing active transactions. This file
is typically only a few megabytes in size and is deleted automatically when the
database is dismounted or the Information Store process is stopped.
This file serves as the transaction log file for the Tmp.edb workspace. This file will never
be larger than 1,024 KB in size.
Single Instance Storage
During the development of Exchange Server, disk capacity compared to I/O capacity was
at a premium; to solve this problem, single instance storage was included in the design.
Single instance storage writes a single copy of an e-mail message or attachment once in
the database and creates pointers for each mailbox in the same database that has a copy
of the object, rather than duplicating the data for each copy. This allows a single 1 MB
Microsoft Word document to be sent to 200 recipients on the same mailbox database but
only be stored a single time, thereby only consuming only 1 MB of space in the database
file rather than 200 MB of space. The potential capacity savings in some environments was
A number of changes have happened over the years that have made single instance
storage less and less practical. First, mailboxes have become larger. In 1996, it was not
uncommon to see a maximum mailbox size of 10 or 25 MB, whereas today 1 GB and larger
mailboxes are becoming commonplace. You might think that this indicates that single
instance storage is now more important than ever, but this is not really the case. Prior to
Exchange 2000 Server there was only an option to create a single Exchange database on the
Exchange Mailbox Services Architecture
server, which made it possible to use single instance storage across all of the mailboxes on
the server. However, now that mailboxes have become larger, more databases are needed on
the server to reduce the individual database size, and because the logical boundary for single
instance storage is at the database level, the return on single instance storage is diminished
with the number of databases that are created.
The Enterprise edition of Exchange 2010 provides you with the ability to create up to
100 databases on a single server, which dilutes the potential for single instance storage savings
even more. Hard drives have also become very large in the last 15 years and will continue to
increase in size, and Exchange server has become increasingly more efficient at working with
lower-performance disk technologies, making space even less of a premium. As a result of
this and the performance improvements made in Exchange 2010, single instance storage is no
longer included in the product. More information about the decision to remove single instance
storage can be found at
The Exchange Services
The Exchange Server Mailbox role installs a number of unique services. It is important to
understand what the Mailbox role does and which services are responsible for specific
functionality so that if problems arise they can be pinpointed and corrected quickly.
Table 6-3 lists the services that are installed specifically to support the Mailbox
TABLE 6-3 Exchange Mailbox Role Services
Microsoft Exchange
Information Store
This required service mounts
and manages mailbox and
public folder databases.
This service must be started,
otherwise none of the
mailboxes or public folders
will be available.
Microsoft Exchange
Mail Submission
This required service submits
messages that are placed in
the hosted mailbox’s Outbox to
the Hub Transport servers. This
service is needed because the
Mailbox server does not have
an SMTP-based delivery service.
In order to send e-mail from
a mailbox this service must
be running.
Microsoft Exchange
Mailbox Assistants
This required service manages
the background processing of
mailboxes in the Exchange
store, including the processing
of out-of-office (OOF) messages
and the managing of calendars
for resource mailboxes.
To provide full functionality
for mailboxes, this service
should always be started.
Mailbox Services
Microsoft Exchange
Replication Service
This service provides the
continuous replication
functionality for Mailbox servers
in a database availability group.
This service should be
running on all members in
a DAG.
Microsoft Exchange
Search Indexer
This service is responsible for
indexing mailbox content.
This service should be enabled
to maintain search indexes.
Microsoft Exchange
Server Extension
for Windows Server
This service enables Windows
Server Backup to work with
Exchange Server 2010.
This service can be disabled
if other backup methods are
Microsoft Exchange
System Attendant
This is a required service that is
responsible for generating e-mail
addresses and offline address
books, updating free/busy
information for legacy clients,
and maintaining permissions and
group memberships for the server.
This service should never be
disabled or stopped.
Microsoft Exchange
This required service limits
the rate of user operations to
ensure that a user cannot create
a denial-of-service situation
by consuming more than the
allowed transactions.
This service should be started
to reduce the possibility of a
single user consuming an
unfair amount of resources.
What Is New in Exchange Server 2010
With Exchange Server 2010, Microsoft has delivered on the following new items: larger
mailbox support through improved performance, better availability options, and a reduction
in the requirements for restores and reduce storage costs.
Large Mailboxes
More and more data is being stored in mailboxes for a variety of reasons. First, users now
send and receive a larger quantity of e-mail messages and the messages are larger in size and
contain different types of attachments than they did in years past. Second, many organizations
must retain more messages in case of litigation or to meet regulatory requirements. With
previous versions of Exchange it was often necessary for users to move data out of their
mailboxes and into Personal Storage Folders (PSTs) because it was too costly for some
organizations to provide large enough mailboxes to meet user’s storage requirements. This
could lead to a number of potential issues, which are described in this section.
What Is New in Exchange Server 2010
With more room in their mailboxes, end users spend less time juggling data to decide
which data should be kept to maintain a threshold under the mailbox limit. Another issue is
that PST files can be lost, stolen, or to a lesser extent become corrupted, potentially losing
or misplacing important or sensitive information. And having data stored in PST files reduces
the likelihood and increases the complexity of a legal discovery being successful in finding
the pertinent and required information and often violates regulatory compliance. Storing
messages within the user’s mailbox rather than in a PST also allows the end user to be able
to access all of her e-mail from all available supported clients such as OWA, Outlook client,
and Outlook Mobile. By architecting and optimizing Exchange Server 2010 to support larger
mailboxes all the issues described above have been addressed.
Deleted Item Recovery and Dumpster 2.0
In previous releases of Exchange Server, as items were deleted they were put into the Deleted
Items folder until the folder was emptied. This gives the end user the opportunity to review
and recover the items before they are permanently deleted. When the Deleted Items folder
is emptied, the messages are specially flagged to be included in the dumpster and essentially
removed from the mailbox. If the end user needs the information after emptying the deleted
items folder, the user can use the Recover Deleted Items option to retrieve the deleted data
for the duration of the deleted items retention set for the mailbox. The items in the dumpster
exist for the duration of the deleted item retention policy or until the items are manually
deleted from the dumpster. The messages in the dumpster are not searchable; there is no
way to enforce quotas on the deleted items and there is no method to block end users from
manually purging the data from the dumpster.
Although the dumpster feature is invaluable in being able to recover deleted information
by greatly reducing or eliminating the need for database restores and performing
MAPI-based mailbox (brick-level) backups, these shortcomings limit the usefulness of the
feature. In Exchange Server 2010, investments have been made to improve this feature.
In versions of Outlook earlier than Microsoft Office Outlook 2007, connected to
Exchange Server 5.5 and later, the Recover Deleted Items option is only shown for the
Deleted Items folder. This often leads some to believe that using Shift+Delete to remove
messages permanently purges the information; however, the deleted information actually
still exists in the dumpster for the folder containing the original message. The Recover
Deleted Items option can be enabled in Outlook by setting the DumpsterAlwaysOn registry
key. More information on setting this registry key can be found at:
Exchange Server 2010 introduces a new version of the dumpster, sometimes referred to as
Dumpster 2.0. Unlike in the previous iteration of the dumpster where the items were flagged
and hidden, Dumpster 2.0 is implemented as a non-IPM folder called Recoverable Items in
each user’s mailbox. Non-IPM folders do not show up as standard folders within the Outlook
or Outlook Web App. This folder has three subfolders: Deletions, Versions, and Purges. Each
is used to provide enhanced functionality to Dumpster 2.0.
Mailbox Services
Deletions Folder
The items that are moved to the Deletions folder are items that are soft-deleted and that
would have ended up in the per-folder dumpster in previous versions of Exchange Server. To
ensure that this works with Outlook 2003 and Outlook 2007, which only understands how the
dumpster works in previous versions of Exchange, the RPC Client Access server will translate
any calls made to the dumpster into calls into the Recoverable Items\Deletions folder. The
Deletions folder data is subject to the Deleted item rendition time set on the database or on
the mailbox.
Using a non-IPM folder to store deleted items allows the following:
Deleted information can be stored per mailbox instead of per folder.
Deleted information can be indexed and searched.
Deleted information can be moved when the mailbox is moved to another database.
In Exchange Server 2010, each mailbox can also have an associated online archive
mailbox, which has a separate Recoverable Items\Deletions folder to store data deleted
from the online archive mailbox.
Purges Folder
The Purges subfolder is used when Single Item Recovery is enabled on the mailbox—if Single
Item Recovery isn’t enabled, deleted items are moved into the Deletions folder. If items are
removed manually from the Deletions folder (when Single Item Recovery is enabled) before
the deleted item retention time has transpired, the messages are moved into the Purges folder
for the duration of deleted item retention. The Purges folder cannot be accessed by end users
and would be used by the administrator to recover deleted data; therefore, this feature solves
one of the deficiencies of previous versions of Exchange where end users could manually
remove deleted items allowing potentially incriminating information to be deleted, if other
measures were not employed. The functionality and usefulness of this feature will be covered
in more detail in Chapter 8, “Automated Message Processing, Compliance, and Archiving.”
Regardless of whether Single Item Recovery is enabled, calendar items are
maintained in the Recoverable Items folder structure for 120 days. However, a legal hold
can enable longer-term data preservation to disable the expiration of the items.
Versions Folder
The Versions subfolder is used when either Single Item Recovery or Litigation Hold is enabled.
Anytime a message in the enabled mailbox is modified the original message is copied to
the Versions subfolder. Each version is kept and can be searched by a user assigned the
Discovery Management role. This is invaluable in finding e-mail messages that might have
been modified to hide or alter the original content of the message. Messages stored in
the Drafts folder are exempt from this behavior to reduce the amount of unnecessary data
in the folder.
What Is New in Exchange Server 2010
The prospect of capturing the versions of modified e-mail messages further reduces the
need for restores resulting from messages being modified. The functionality and usefulness
of this feature will also be covered in more detail in Chapter 8.
The Dumpster 2.0 configuration options are summarized in Table 6-4.
TABLE 6-4 Dumpster 2.0 Configuration Options
Single Item
Yes, using
deleted item
retention for
e-mail and
120 days for
calendar items
Single Item
Yes, using
deleted item
retention for
e-mail and
120 days for
calendar items
Hold enabled
Discontinuation of Storage Groups
In earlier versions of Exchange Server, you could create multiple databases that used a single
set of log files. These collections were called storage groups and were allowed so that
databases could be kept smaller and more manageable. However, because of the limited
cache memory available in 32-bit versions of Exchange Server, only four storage groups with
a maximum of 20 databases could be created on a single server.
Storage groups continue to exist in Exchange Server 2007; however, having multiple
databases in a single storage group is generally discouraged or prohibited in many
configurations. With the ability to create up to 50 storage groups and as many databases
on a single server, the best practice is to never create more than one database in each storage
group, but rather create a storage group for each database.
In Exchange Server 2010, storage groups have been completely eliminated. Now each
set of transaction log files only supports one mailbox or one public folder database. Not
only have the storage groups been eliminated, but databases are also no longer specifically
owned by any single server. All of the database objects now reside within a single database
container for the entire Exchange organization. In the Exchange Server versions 2000, 2003,
Mailbox Services
and 2007, a database name only had to be unique within a storage group. A database could
be distinguished by the server it was created on and the storage group it was created within,
as shown in Figure 6-3. Because of this many companies could have rightly used the same
database names multiple times across the entire Exchange organization.
FIGURE 6-3 Distinguishing database names in Exchange 2007
In Exchange 2010 databases are no longer tied to a specific server. Therefore, each mailbox
database name must be unique across the entire organization, as shown in Figure 6-4.
This means that proper attention must be given to creating a naming standard that works for
your organization. The best practices for creating a naming standard for an organization are
discussed in further detail in Chapter 3, “Exchange Environmental Considerations.”
FIGURE 6-4 Distinguishing database names in Exchange 2010
Exchange Server 2003 also introduced the Recovery Storage Group feature; this feature
enables an administrator to restore database backups into a special storage group for
recovery. This functionality still exists within Exchange 2010; however, with the removal of
storage groups it is now called a recovery database (RDB). The functionality and best practices
for using RDBs are covered in Chapter 12, “Backup/Restore and Disaster Recovery.”
Performance Improvements
The overall theme for the storage changes in Exchange Server 2010 was to move away from
doing many random, small, disk IOs to a few sequential, large, disk IOs. A number of changes
were done to accomplish this, such as a larger page size, improved data contiguity, and more
intelligent I/O operations.
The importance of optimizing I/O can be better understood by reviewing how disk
technology functions. Random disk I/O is bound by the speed at which the disk head can
What Is New in Exchange Server 2010
move around and get data. The more the disk head has to move the longer it takes to read or
write data. When data is read or written contiguously the disk head does not need to move
between operations and can execute I/O at a much higher rate, primarily dependent on the
speed at which the disk spins.
Although improvements have been made in this regard by improving the rotational speed
and the aerial density of the disk platters, random reads and writes do not perform nearly as
well as sequential reads and writes. The performance improvements for sequential reads and
writes have far outpaced the performance improvements for that of random reads and writes.
Thus by changing the format that the data is read and written in, more performance can be
extracted from the same disk hardware already in use.
Optimizing this I/O opens up possibilities for you to use storage types that would have
never even been considered, such as SATA disks, which generally have good sequential I/O
performance, higher storage density, and lower cost than Fibre Channel or Serial Attached
SCSI storage technologies, but have poorer random I/O performance. The size and speed of
the database storage are typically the largest capital cost factors in an Exchange solution. In
the end, optimizing Exchange to allow for the design of solutions using lower-cost SATA disks
means lower-cost solutions with better performance.
Choosing a Disk Technology
Steve McIntyre
Solutions Architect, Dell Inc.
hoosing the right technology for a messaging system requires that both current and
future needs are met. To do that it is important to choose the right disk technology
that meets the performance and storage needs of the Exchange Server deployment. The
following tables show the current state and predicted future advances in both Serial ATA
(SATA) and Fibre Channel (FC) and Serial Attached SCIS (SAS) disk technology. The first
table shows the past and estimated capacity and speed of 3.5-inch SATA disk drives.
Drive Capacity (GB)
Rotational Speed (RPM)
The second table shows the past and estimated capacity and speed of 3.5-inch FC
and SAS disk drives.
Drive Capacity (GB)
Rotational Speed (RPM)
Mailbox Services
As you can see, the RPM for FC and SAS disks is not expected to improve at all in
the next few years. Therefore, there will be no random I/O performance gains for
Exchange Server. Also, the capacity available in SATA disks far outstrips the capacity
available in FC/SAS disks, which means that optimizing Exchange to use SATA
technology provides a greater “bang per buck” for companies deciding on their disk
Increased Database Page Size
To accomplish these performance goals, a number of core changes were made to the
database. The information inside the database is stored in B-trees, and these B-trees are
segmented into pages where the data is written. The page size then sets the minimum size
for any sort of I/O operation to the database. The first fundamental design change was that
the page size was increased from 4 KB to 8 KB in Exchange Server 2007, which contributed
to a large improvement in performance. In Exchange Server 2010 the page size has been
increased all the way up to 32 KB. This increase in page size means that each I/O can now
either write or read four times the amount of data than in Exchange Server 2007, which
translates into needing less I/O and improved performance.
Improved Data Contiguity
To perform fewer random I/O operations the data needs to be written to the disk in
a predictable, non-random fashion. When data is made contiguous and database pages
are written to the database in order, the database gains a little extra whitespace. When data
is compacted, the data is moved in the database to consolidate the whitespace in one area
within the database file. As might be apparent here, contiguity and compaction work in direct
opposition. Compaction preserves and consolidates whitespace and contiguity often leaves
whitespace within the database to ensure that data is written contiguously. In the earlier
versions of Exchange, the defragmentation process favored compaction over data contiguity
to maintain the smallest available database file size.
In Exchange Server 2010, contiguity of data is preferred over compaction of data.
In testing, the changes that were made to the database added about 20 percent
of whitespace into the database. To combat this bloat, compression of message
headers and text or html message bodies was added to the database, which in testing again
shrank the database size around 20 percent. The results of these changes leave a much
more contiguous file with better read and write performance than previous versions of
Exchange Server.
As the data is written into the database, the store will look for space within the database
so that the data can be written contiguously. Figure 6-5 shows how a single empty page is
skipped to store a message header and message body contiguously within the database.
What Is New in Exchange Server 2010
Data that does not need to be written contiguously will opportunistically be stored in
the blank pages; the figure shows a page with event history being written to the
empty page.
DB Cache
Page Y
Page X
Page 1
Page 2
Page 3
Page Z
Page 4
Page 5
FIGURE 6-5 Contiguous page usage
Not only is contiguity built into the initial creation of the data, but processes are also in
place to ensure that the data is maintained in this state, even as it is accessed and modified
by the end clients.
The database defragmentation process has been improved to reduce I/O operations.
Defragmentation is now performed in-place, rather than creating a new B-tree and then
renaming all of the indexes and tables. This reduces the number of I/O operations that
need to be completed. Data is read from and written to the hard disk from right to left—
right merges require more disk head movement to complete. The defragmentation
process in previous versions used right merges, meaning the data is read and then moved
to the left or earlier in the file. With left merges, the data is read and then moved to the
right, or the same direction as the I/O operation. Because space is allocated also from
left to right, and page moves need to allocate a new page, defragmenting the database
from left to right is much more efficient because it reduces the need to move the hard
disk head.
With the improvements to the performance and added throttling to the defragmentation
process, it is no longer required to run the process only during off hours. To be sure that
contiguity is maintained, defragmentation is set by default to run continuously. As shown in
Figure 6-6, the defragmentation and compactions processes will move items to maintain the
optimal contiguity of the database, even after a user has disrupted the original contiguous
Mailbox Services
Mailbox Messages
Mailbox Messages
User Deletes
Mailbox Messages
FIGURE 6-6 Maintaining contiguity over time
Intelligent I/O Operations
Not only has the schema and contiguity been improved, but there are also a number of
changes to improve the way I/O is done. (As the saying goes, work smarter, not harder.)
Rather than pushing the limits of the hardware, intelligence was built in the product to
improve how and when I/O operations are done. These improvements include I/O gap
coalescing, smarter view updates, and smoother database writes.
With improved contiguity, coalescing—combining adjacent I/O operations—is now more
viable. Exchange Server 2007 was able to coalesce adjacent I/O operations to reduce the
number of I/O needed to write database changes. Exchange Server 2010 introduces the
ability for gap coalescing, which is the ability to group nearby read or write operations
together into a single I/O operation. This can be illustrated, as shown in Figure 6-7, when
Exchange is reading a message from disk. Rather than initiating a read I/O for the page
that contains the message header and then several additional read I/O operations to get
each of the pages that contain the message body, Exchange will initiate a single read I/O
that reads all contiguous pages from the message header through the last page that contains
the message body and discard any unneeded pages. In this example the Exchange Server
2010 gap coalescing would require two fewer read I/O operations, and provide a much higher
rate of I/O.
What Is New in Exchange Server 2010
Page 1
Page 2
Page 3
Page 4
Page 5
Cache Header
1 Read IO
Page 1
Page 2
Page 3
Page 4
Page 5
FIGURE 6-7 Coalesced read operations in Exchange Server 2010
In Exchange Server 2007 and earlier, anytime that an e-mail message impacted a view, the view
was immediately updated. In Exchange Server 2010 the only time the view is updated is when
it is being accessed. This is shown in Figure 6-8 using the Unread or Flagged items view. The
top of the figure shows how, in Exchange Server 2007, any changes to the view require it to be
updated immediately. At the bottom of the figure you can see that in Exchange Server 2010,
the same actions occur; however, the view is only updated once, when that view is accessed
by a client. This example has a five-fold reduction in the number of I/O operations that are
required. This again greatly reduces the number of I/O operations that need to occur. It might
seem that making the updates when a view is accessed would add latency; however, with the
other database changes that have been made the overall performance is still improved.
All Unread or Flagged Items (view)
Exchange Server 2007
Many, Random, I/Os (1 Per Update)
Arrives Arrives
All Unread or Flagged Items (view)
Exchange Server 2010
Fewer, Sequential, I/Os (1 Per View)
FIGURE 6-8 View updates utilizing sequential I/O
In a typical database, anytime I/O needs to occur the database will immediately send all of
the I/O requests to the storage. This causes larger bursts of work that needs to done. Most
applications will allow the burst of work to be handled by adding disks or cache to the disk
Mailbox Services
subsystem. However, with these bursts of work also comes disk contention, which means
that the work takes additional time to complete, or adds latency. As mentioned earlier in the
chapter, the faster the disk spins the faster that random I/O operation can occur. This also
correlates with the number of concurrent operations that a disk can handle adequately.
Disk contention during these bursts can be likened to pouring a liquid into a funnel.
When you pour the liquid into the funnel at roughly the same rate the liquid passes through
the bottom of the funnel, the funnel will not overflow. If the liquid is poured too fast, it will
overflow and cause a mess. The solution is to get a bigger funnel or change the rate at which
the liquid is poured into the funnel. Rather than requiring a bigger funnel—more expensive
hardware—Exchange Server 2010 uses database write smoothing.
Database write smoothing throttles disk writes to reduce disk contention while still
maintaining the checkpoint target. This also better accommodates slower-spinning disks
and multiple workloads on each disk. Database write smoothing cannot be manually
configured and is always enabled, following these rules:
When the checkpoint depth equals 1 to 1.24 times the checkpoint target, database
write smoothing limits the maximum writes for each LUN to one.
When checkpoint depth equals 1.25 times or more of checkpoint target, database
write smoothing begins to increase the maximum writes for each LUN. The farther
the target falls behind the checkpoint, the more aggressively it raises the maximum
outstanding writes/LUN, with a total maximum of 512.
Caching information in memory reduces the number of times the disks need to be accessed.
Because memory is far faster than disk, the more accurate and complete the caching is,
the less disk I/O is needed and the faster the information can be used. Cache warming is
a process that preloads queries that were executed against a database the last time the
database was started. After a server restart, failover, or switchover, the larger I/O allows ESE
to increase the rate at which the cache is warmed. The information store process is now used
to replay the logs on the passive copy of the database, which allows a cache to be populated
with recently used information to be in memory. This is unlike Exchange Server 2007, which
used a separate process to replay the logs, limiting the cache effectiveness in a switchover
Another way caching was improved was by increasing the checkpoint depth. The
checkpoint depth is the amount of data waiting to be committed into the database file.
The checkpoint depth has been increased to 100 MB when the database is configured in
a Database Availability Group (DAG); however, the limit is still 20 MB for databases not
configured in a DAG. It turns out that when a database page is written to, it often is rewritten
to shortly thereafter. This makes sense, because when a user receives an e-mail message, he
may read it, set it for follow-up, or move it to another folder. By waiting longer to commit
the changes to the database pages, the subsequent changes are made in the database cache,
and then a single I/O is performed to the disk that encompasses all of the changes.
What Is New in Exchange Server 2010
In Exchange 2000 Server, it was common and supported to manually reduce the checkpoint
depth from the default 20 MB to a lower depth in a clustered environment to improve
switchover times. This is because when a switchover occurred from one clustered node to
another, all of the outstanding transactions needed to be completed on the active node
before the switchover or shutdown could complete. In Exchange Server 2010, this does not
happen because the passive copies of the databases have a checkpoint depth of only 5 MB.
With only up to 5 MB of outstanding transactions, these can be committed quickly, allowing
for faster switchover operations. Also, Exchange 2010 allows all databases to failover in parallel,
which improves the shutdown and the speed of committing the data before the switchover.
No matter how large the cache is, if it doesn’t have valid or useful cached information it
doesn’t do any good. To keep the cache fresh with valid cache data, the Exchange Server 2010
cache allows lower priorities to be set to cache data that has limited usefulness. Cache data
generated from database maintenance activities such as online defragmentation, database
check summing, and passive copy log replay all are given lower priorities so that the data can
be evicted from the cache more quickly.
With page sizes four times larger than previous versions, only a fourth of the number of
pages can be cached in the same amount of memory. To combat this potential ineffectiveness,
database cache compression, also known as cache dehydration, was introduced. This removes
the whitespace and only stores the active data from each of the 32 KB database pages in
memory. For example, if a database page only has 16 KB of data written to it, only the 16 KB
of data is stored cached, rather than caching the entire 32-KB page. This allows additional
pages to be cached and provides a more effective database cache.
Online Archive
Personal Storage Files (PSTs) are a problem for many Exchange users because they are not
backed up or physically protected and can contain confidential information or have data
needed for legal discovery. This information can be lost or fall into the hands of unauthorized
people. Many solutions have been put on the market to help control the PST sprawl in
a company. Some of these solutions will search for and then gather and index the data within
the PSTs and store them in centralized repository. These solutions can scale well and have
become fairly mature products. However they often require a separate access method or
Outlook plug-ins to access the archived data. The online archive, although it lacks some of
the more sophisticated tools that third-party products offer, does allow access to the archived
data through Microsoft Office Outlook 2010 as well as through Outlook Web App (OWA)
without requiring the installation of additional software on each client computer or device.
High-Availability Improvements
In recent years the market trend has been to use larger and more sophisticated SANs (storage
area networks) to provide redundancy and failover solutions.
In stark contrast, the Exchange product team has been reducing the need for expensive
SANs and complicated replication topologies by reducing the disk I/O requirements for the
product and by building robust replication technologies directly into Exchange that are
Mailbox Services
better able to understand the health of the application. The two factors that influence the
high-availability options in Exchange Server 2010 are the reduction in disk I/O requirements
and subsequent improved performance on inexpensive and non-RAID protected disk,
and the introduction of the DAG.
RAID-less Storage Deployments: An Emerging Industry Trend
ith the emergence of cloud computing, the trend has been toward
inexpensive, highly available computing and storage. Cloud computing
vendors offer large amounts of storage over the Internet for a small monthly fee.
To drive down costs many of these storage vendors rely on commodity hardware
and custom-written software to provide redundancy rather than expensive RAID
and SAN configurations. The storage is often comprised of low and mid-tier
high-capacity hard drives attached to server computers without RAID controllers or
SAN connectivity. RAID and SAN configurations copy data at a bit level on the disk,
usually with little understanding of the files and format of the data.
Clients then attach to the service using a common storage protocol or proprietary
API, and the storages service takes care of making multiple copies of the data,
either on separate disks on different servers in the same site or in multiple sites
to provide redundancy. This configuration for cloud storage vendors saves money
during the initial purchase because it does not require a SAN configuration, and
it does not require specialized datacenter staff to manage and maintain a SAN.
This also provides fewer single-points-of-failure because the data is spread out on
multiple disks and multiple servers. If any single failure were to occur, the likelihood
that it would affect data availability is greatly reduced.
Traditional SANs will present a logical unit number (LUN) to a host server that has
a specific RAID type. All data that is stored on this LUN is striped or mirrored across
all of the physical disks on the underlying group. Therefore, all files stored on this
LUN share the same redundancy. Using software to provide redundancy on multiple
independent storage devices provides additional flexibility because each file can
be given a different protection level and copied as many times as needed for
redundancy and availability.
The cloud is not the only place this trend away from hardware RAID has been seen.
Microsoft Home Server, a consumer product aimed at home storage networking,
also uses software to control data redundancy at a file level rather than relying on
software or hardware RAID. This allows the product to aggregate storage across
different hard drive sizes and technologies and provides a unified files system to
store data and still provide redundancy in case of inevitable hardware failure.
It is clear this is a new trend toward file-based, RAID-less redundancy in the
industry—a trend that is apparent in the design of Exchange 2010.
What Is New in Exchange Server 2010
Exchange Server 2007 introduced a number of new options for availability that previously
required special network and SAN hardware. The following availability options are available
in Exchange Server 2007 SP1:
Cluster Continuous Replication (CCR) is a two-node clustering solution that requires
no shared storage and maintains two full copies of the databases to protect against
server and storage failures. The data is kept in sync by replicating the transaction logs
from the active to the passive node of the cluster. The passive node then applies the
transaction logs to the passive copy of the database.
Standby Copy Replication (SCR) is an availability option that does not require
clustering, and can provide multiple passive database copies on multiple servers. The
database copies can be set to not apply logs for up to seven days so as to provide for
point-in-time recovery. Activating a passive copy requires administrative intervention.
SCR was first introduced in Exchange Server 2007 SP1.
Single Copy Cluster is similar to traditional Exchange clustering in that it does use
shared storage; however, in Exchange Server 2007 the setup process, stability, and
overall management process was greatly improved.
Local Continuous Replication is a single-server, data-redundancy solution that
maintains two full copies of the databases to protect against local storage failures.
Activation of the passive copy requires administrative intervention.
The improvements included in Exchange Server 2010 combine many of the benefits
available in Exchange Server 2007 SP1 along with a few other improvements into the DAG.
The DAG is a group of up to 16 Exchange Server 2010 Mailbox servers that can each maintain
up to 100 databases with a total of up to 16 copies of each database on as many different
servers in the DAG.
The DAG differs from Exchange Server 2007 SP1 in the following ways:
With CCR, there can be only two copies of the database within the cluster; within the
DAG there can be up to 16 copies of each database.
With SCR, the activation process required administrative intervention; within a DAG,
failover between individual database copies can happen automatically.
With SCC, a single copy of the database consumes less storage but provides
no redundancy. There is no configuration in Exchange Server 2010 that replaces
this functionality, although some third-party solutions may provide similar
With LCR, a single-server configuration allows two copies of a database to reside on
different storage connected to the same server. There is no configuration in Exchange
Server 2010 that replaces this functionality.
Mailbox Services
Discontinuation of Single Copy Clusters
uring the development of Exchange Server 2010, a small number of people
hung onto the legacy high-availability and data redundancy solutions such as
SCC, and requested that these functions be retained in the product. In the end, the
benefits did not outweigh the negatives. SCC was usually deployed in situations
where failover operations needed to be minimized or where companies already
had a significant investment in SAN hardware. However, SCC was never promoted
as a best practice by Microsoft. There are a number of reasons for the diminishing
return of SCC:
It does not cover for storage failures.
It requires third-party products for multi-site failover.
It only provides protection from hardware failures and operating system
issues and reduces downtime for software updates.
It requires shared SAN storage—often the most expensive disk.
In the event of an information store issue, the service restarts on the same
cluster node without any protection from downtime.
The fact remained that the solution still maintained the most critical single point
of failure—a single copy of the database—did not meet the requirements of
customers. A DAG configuration covers the single-point-of-failure problem and
also protects against hardware and operating system issues. With the reduction
in the required disk I/O, high-performance SAN-based disk is no longer required.
Therefore, even if double the amount of disk is required to provide two copies of
the database, quite often the storage costs are still significantly less for an Exchange
Server 2010 DAG over a similarly configured Exchange Server 2007 SCC cluster.
Exchange Mailbox Services Configuration
Much of the configuration that is done for the Mailbox server role is done during the
hardware configuration and installation of the Mailbox role. After the Mailbox role is installed,
creating and configuring databases usually completes most of what needs to be done. After
the deployment is completed, management of mailboxes and public folders is usually the
extent to which the Mailbox server is managed. When you install Exchange, you need to
consider a number of important things.
Exchange Mailbox Services Configuration
One of the biggest considerations is where Exchange should be installed and how the
disks should be configured for the databases. As best practice it is always good to have the
operating system and the system page file configured on separate RAID1 or RAID10 disks.
As with Exchange Server 2007, each database needs to be located on the same path
on each server that will host a copy. When deploying a DAG with more than 22 different
databases, managing drive letters might be a challenge. Rather than assigning each drive
a new letter, they should be assigned mount points on a RAID-protected volume. Following
this best practice will allow more than 24 disks to be used and provide flexibility to remount
a replacement disks to that mount point quickly in case of a failure. If the disk that hosts the
mount points fails, the mount points will also become unavailable. Protecting the mount
point host volume with RAID will ensure that a single disk failure will not cause all of the
databases to go offline.
This chapter has covered a number of the storage improvements that have been made
in Exchange Server 2010. These changes affect all aspects of design and should cause
experienced Exchange administrators to reconsider a lot of the accepted assumptions that
have become rote. One of these is the need to ensure that the transaction logs and the
database must be on separate physical disks. With the lower I/O requirements and database
write smoothing, this no longer becomes a problem with disk contention. There are still
reasons that it might be good to split the transaction logs and databases on separate volumes
or disks. One such reason is to not allow growing transaction logs to run the disk out of space
and cause the database to go offline. In a stand-alone deployment it is still important to store
the transaction logs on separate disks from the database so that in the event of a disk failure,
both the transaction logs and the database are not lost. In a high-availability deployment,
multiple copies of the data already exist on other servers.
Segregating Database and Transaction Logs
Thierry Demorre
Senior Director, Infrastructure Services Line, East Operating Unit, Avanade Inc.
lacing Exchange database files and transaction logs on disk has always been
a subject of discussion between Exchange design engineers and the storage
engineers. Usually the former wanted to split those files across different physical
disks while the latter preferred a single large aggregate and lay out all of those files
together. Exchange Server 2010 provides a simple solution to this design argument
thanks to two major improvements over previous Exchange versions: DAGs and
a new I/O profile.
Mailbox Services
Database Availability Groups
Three or more copies of a database means more redundancy than in a typical
RAID 1 or RAID 5 configuration, which is enough redundancy for your database and
transaction log files. In the event of a failure of one of the instances, the remaining
data is not affected. Therefore, having the database and transaction log files sharing
the same physical disks should not be a concern.
Extensible Storage Engine (ESE) I/O Profile
The ESE went through a major overhaul in the way it handles disk writes. All of
the previous versions of Exchange have always written small, random blocks of
data. Now, ESE has been optimized for large sequential writes, which from a disk
activity perspective translates to most database writes being sequential. Because
transaction log writes are also sequential, mixing those two I/O profiles on the same
physical disks will not affect the scaling capability.
Determining the Number of Mailboxes
for Each Server
A number of factors go into deciding the number and size of mailboxes that should be
placed on a single server and how to configure the number of mailboxes that should be
placed in each database. The final decision will weigh several key factors, such as the size,
relative importance, and, most important, the service level agreement (SLA) required for
the mailboxes.
Although 10,000 mailboxes provided to university students with a maximum quota
size of 25 MB at no cost may take up more space than 250 executives with a maximum
quota of 10 GB, the former mailboxes are arguably far less important. Weigh this relative
importance against the number of mailboxes that can be recovered within the SLA. When
it comes down to it, database size is often governed by your redundancy design. Designing
a solution for backup and recovery that meets these needs will be covered in more detail
in Chapter 12; designing highly available solutions that may reduce the need for restores
will be covered in detail in Chapter 11, “Designing High Availability.” In both of these areas
improvements have been made to reduce the need and improve the speed of recovery
should it be required. With these changes and careful planning it usually is possible
to increase the size that the databases should be allowed to grow.
Exchange Mailbox Services Configuration
How Many Mailboxes Should Be Created on a Server?
Thierry Demorre
Senior Director, Infrastructure Services Line, Avanade Inc.
wo of the most common questions about Exchange are “How many mailboxes
can I fit on this server?” and “With this new version of Exchange, will we get
twice as many mailboxes on a server than in the previous version?” Unfortunately,
these questions have no definitive answers, because of a number of contributing
factors to both the performance and the space requirements for an Exchange
mailbox server. These are the two principle factors to take into consideration for
appropriately sizing an Exchange Mailbox server.
Actually, asking how many mailboxes can be hosted on a server is not the correct
question. A better way to approach the question would be to ask, “How many 1-GB
mailboxes, with a medium profile usage, having a 90 KB average message size,
with single item recovery configured for 20 days and calendar versioning can I host
on my server with 16 cores that run at 3.4G Hz and have 32 GB of RAM and are
connected to 48, 1-TB-large form factor 10,000 RPM SAS hard drives?” Although the
qualification statement is wordy, it does properly identify the target usage for the
mailboxes. Having this level of detail when asking this question will provide a better
basis for answering the question using the right tools.
The best practice here really is two-fold: first you need to understand what you are
sizing for, and second you need to validate your assumptions against the Mailbox
Server Role Requirements Calculator published by the Exchange product group. To
do the former you must investigate the current environment and profile the users
that will be migrated or transitioned to the new environment. To do the latter you
should download and learn to use the calculator. The calculator takes extensive
testing done by the product group and wraps it into a fairly simple Microsoft
Office Excel spreadsheet. This calculator should be the starting point at any serious
Exchange design. After gauging the configuration sizing using the calculator you
should use the information you have gathered to configure tools such as JetStress
and Load Simulator to prove the calculations are correct.
After verifying the number of mailboxes that can be hosted on the configured
servers, the last question that needs to be answered is how many is too many? As
the number of mailboxes on a server grows, the number of users that would be
affected in the event of a single server outage or degradation of service increases.
Employing high-availability best practices can curb many of these problems;
however, there is still risk in placing too many mailboxes on a single server rather
than scaling out the same number of users across multiple servers.
Mailbox Services
Determining Where to Host Mailboxes
A number of best practices are defined for placing mailbox servers and mailboxes on these
servers. As you define the location of each of your user populations, the network connectivity,
server and storage capabilities, and skill sets available at each site, where to place the servers
may become clearer.
Several configurations are used to define the configuration, as seen in the example
solutions used in this book. The Litware deployment is a distributed environment with
Exchange mailbox and other services pushed out to the remote sites. This has several
advantages, especially if the users at the remote offices primarily communicate with each
other. Because users primarily communicate with each other, the majority of the e-mail
messages stay within the site and do not need to traverse the network. The side benefit of
this is that in the event of network issues where the remote site loses connectivity back to one
of the corporate sites, the local users can continue to send and receive e-mail. The downside
of this configuration is that support for the remote servers can be challenging especially if
physical access is needed to repair the hardware.
The Fabrikam deployment uses a more centralized deployment. The benefit of this type
of deployment is that mailbox services are concentrated in locations that have appropriate
network connectivity and support staff to handle monitoring and maintenance of the
hardware and software.
The best practice for determining where to host mailboxes depends on what fits the
business requirements, network requirements, and administrative requirements. The principle
should always be to keep the design as simple as possible while still achieving the goals. You
need to ask several key questions when determining where to host mailboxes:
Is there adequate and redundant bandwidth available between the clients and the
Exchange servers?
If the Exchange servers will be hosted at a remote location, how will backups, hardware
maintenance, and monitoring be accomplished?
Does the remote site have adequate power, cooling, and network connectivity?
Database Maintenance
Database maintenance is divided into two parts: store mailbox maintenance and ESE
database maintenance. Store maintenance includes performing cleanup within the database;
ESE database maintenance includes online database scanning (database checksum),
defragmentation, and compaction.
Database Cleanup
Database cleanup involves identifying newly disconnected mailboxes and evaluating the
deleted item retention period on deleted messages and mailboxes and purging any items
that have expired. Database cleanup is now the only task that is, by default, configured
to run during the online maintenance window. Although online maintenance no longer
consumes as many resources as it did previously, it is recommended to schedule the
Exchange Mailbox Services Configuration
maintenance window after the backup window. This will allow backups to capture data
before they are purged from the database. Configuring the online maintenance schedule
is shown in Figure 6-9.
FIGURE 6-9 Configuring the database online maintenance schedule
Online Database Scanning
The integrity of data within the database is of the utmost importance—if there is a physical
page corruption, it is important to know about it so that something can be done. Often
this type of corruption is due to a problem with the underlying storage. In Exchange Server
2007 RTM and earlier versions, each page was scanned during backups using the streaming
API. With the deprecation of the streaming backup API in Exchange Server 2007 and the
removal of it in Exchange Server 2010, another facility to ensure data integrity was needed.
In Exchange Server 2007 SP1 an option was introduced to run a database checksum during
the scheduled online maintenance window.
In Exchange Server 2010, the default setting allows the online database scanning to run
in the background continuously. Alternatively, the online database scan process can be set
to run only during the schedule online maintenance window; however, because of the time
it takes to complete, this is only recommended for databases smaller than 1 terabyte (TB).
The best practice is to leave the default setting and allow the scanning to run continuously.
Defragmentation and Compaction
Defragmentation and compaction happen at run time and are balanced to provide
data contiguity rather than to optimize space. Table 6-5 summarizes each type of online
maintenance activity and how they have been improved in Exchange Server 2010.
Mailbox Services
TABLE 6-5 Comparing Online Database Maintenance Operations
Performed during online
defragmentation, which
occurs during online
ESE performs cleanup at run
time when a store hard delete
occurs. This happens during
dumpster cleanup during the
online maintenance.
Database checksum
When configured, half of
OLD maintenance window
reserved for sequential
scan (Checksum), manual
throttle. Active DB
copy only.
Two options (both active and
passive copies):
Maintain contiguity
N/A (compaction
activities during online
defragmentation prevent
data contiguity).
Database is analyzed at run
time and is defragmented in
the background.
Space compaction
Database is compacted
and whitespace is
reclaimed during online
Database is compacted and
space reclaimed at run time.
Run DB Checksum in the
background 24 × 7
Run DB Checksum during
online maintenance.
Offline Maintenance
One of the most frequently asked questions continues to be, “How often should you
do an offline defragmentation of a database?” The trigger of this question in previous
versions of Exchange Server was often Event ID 1221, which detailed the amount of free
space available within each database after a full online database defragmentation pass was
completed. Many messaging administrators would see this free space as an indicator of
inefficiency and want to reduce the size of the database to improve performance and reduce
the backup size. Because defragmentation and compaction are now continuous processes
in Exchange Server 2010, there is no longer a point in the process when the free space
within the database base is published to the event log. There is a way, however, to get this
information using the Exchange Management Shell. For example, the cmdlet to find the free
space in Dallas-EX01-MB04 would look like this:
Get-MailboxDatabase Dallas-EX01-MB01 -Status | Format-List AvailableNewMailboxSpace
Exchange Mailbox Services Configuration
When using the Get-MailboxDatabase cmdlet, the –Status switch must be specified
to be able to view the available space, whether online maintenance is running, whether
the database is mounted, or whether a backup is in process. If the –Status switch is not
specified, the information returned by the cmdlet is retrieved from Active Directory
Domain Services. When the –Status switch is specified, the additional information is
retrieved directly from the Mailbox server.
As with previous versions of Exchange, even with a significant amount of free space
available in the database, more efficient ways are available for reclaiming this space. Using
database tools such as ESEUtil.exe requires that the database be taken offline and that
enough space is available on disk to complete the maintenance. Although the performance of
ESEUtil has improved, it still requires extended downtime for all mailboxes hosted within that
database. A much more reasonable approach would be to create a new blank database and
move all of the mailboxes from the bloated databases into the newly created database. For
example, the command to move all mailboxes from Dallas-EX01-MB02 into Dallas-EX01-MB22
would look like this:
Get-Mailbox –Database Dallas-EX01-MB02 | New-MoveRequest –Local –TargetDatabase DallasEX01-MB22
If a physical corruption is found in the database during the online database scanning
(database checksum), this same process can be used to move all mailboxes to a newly created
database and delete the problematic database. This eliminates the need to take the database
offline to repair it, which caused extended downtime for the affected mailboxes.
Mailbox Limits
As a seasoned Exchange administrator you have most likely heard from someone that
“Storage is cheap, why must you put a limit on my mailbox rather than just adding more
disks?” For a number of really important reasons, adding disk alone is not the answer.
The primary reason is to meet SLAs. Without established mailbox limits, an SLA violation
could occur in a number of ways. For instance, if none of the 5,000 mailboxes on a mailbox
server had limits imposed, any single mailbox could consume all of the disks on a server in
a matter of minutes. Although this could happen as the result of a malicious act, it can also
be unintentional in a case where an Outlook rule or outside service continues to send e-mail
messages to a mailbox, causing it to grow larger until the underlying storage fills up. With
the improved performance and faster server hardware, these sorts of actions can happen in
a matter of just a few minutes.
The other way mailbox limits play into achieving an SLA and controlling the size of
databases has to do with achieving expected backup and recovery times. To recover the data
in a database within the agreed-upon SLA, the databases must be under a specific size. For
example, if you can restore 150 GB of data from your backup solution in three hours, and
you have a four-hour SLA to restore the data, you do not want to allow the database to grow
Mailbox Services
larger than 150 GB; otherwise, anytime a restore is required, the SLA will be violated. The
easiest way to implement and maintain control over the size of the databases is to establish
limits on the mailboxes and thereby not allow them to cause the database to grow beyond
the size that prevent SLAs from being met.
This really means there is no hard and fast rule on how big mailboxes should be—just that
a maximum size should be set. The best practice is to set a limit that in aggregate is less than
the available disk space. That way if all mailboxes on the server reach the limit, the server will
still have space to continue operating. That said, this may not be completely feasible, nor is it
probable that all users will use their entire quota at the same time, unless there is malicious
intent. In this case it is important to weigh the risks and costs involved.
Appropriately Sizing Mailboxes
Thierry Demorre
Senior Director, Infrastructure Services Line, Avanade Inc.
t some point during the design phase of a new Exchange environment comes
the decision of the mailbox size. This decision prompts questions like “How
much should we allocate?”, “Should all mailboxes have the same limits and retention
policies?”, and “Should users have mailbox sizes that coincide with their job
function, and if so how would that be determined?” It is appropriate to answer all
of these questions before doing everything else, and that requires knowing the big
picture of where you are deploying Exchange. To do this you will need to interview
the legal team to understand what the retention policy needs to be. For example,
if the legal team wants everything older than six months purged and inaccessible,
that will need to be the starting point for evaluating the mailbox size.
On the other hand, if no restrictions are to be put in place, evaluation of the
Exchange Server 2010 online archive or third-party archiving solution should
be done along with determining the potential impact to the configuration and
performance of implementing the archiving solution. Most of these archiving
companies have been singing the praises of their products, and especially how
stubbing items being archived was a way to save space in your online mailbox.
As a best practice, however, using any form of stubbing is a bad approach. This
has always been a limiting factor in Outlook—performance can degrade when
the number of items grows out of control. While Outlook 2007 SP2 and Outlook
2010 introduce technology improvements for many more items in each folder, as
well as larger mailboxes, keeping the environment under control is of paramount
importance to keep the performance optimal for the end user. It is important to
archive smart, rather than retaining data just for the sake of retention.
Exchange Mailbox Services Configuration
The appropriate course is to evaluate this question as any other critical aspect of
your design. It would be wise to interview representatives from a number of user
groups and obtain their requirements. It might be that one group only cares about
the last three weeks' worth of e-mail, and another group that has a completely
different or conflicting requirement. It would also be good to obtain some less
subjective data, perhaps by creating a trend of current mailbox sizes. Because older
versions of Outlook may not perform properly with large mailboxes or will not
provide access to new features available in Exchange Server 2010, it is important to
identify the client software that will be used. I know of companies that will deploy
Exchange Server 2010, and then continue to use Microsoft Office Outlook 2003 to
connect to their new messaging system.
So, how do you answer the question, “Can I create a 1-TB mailbox?” It is true that
Exchange Server 2010 will certainly allow this. However, the reciprocal question
would be, “Will you use it?” If you fill that mailbox with messages with an average
size of 50 KB, that is approximately 24.5 million messages!
Configuring Deleted Item Recovery Quotas
Configuring the deleted item recovery setting needs to be done after the business needs
are captured and understood. However, a couple of settings should be configured to ensure
that malicious users cannot cause Denial of Service attacks by placing large amounts of data
into the dumpster and running the server out of space. To do this the RecoverableItemsQuota
and RecoverableItemsWarningQuota settings should be set per database. However, the
settings can also be done per mailbox. These settings are similar to mailbox quotas except
that they apply to items in the dumpster:
RecoverableItemsQuota The default limit is 30 GB; however, this can be set as
needed. When the limit is reached all soft deletes will fail and an event log entry will
be made the first time it occurs and once daily if the condition continues.
RecoverableItemsWarningQuota The default limit is 20 GB; however, this can
be set as needed. When the limit is reached, an event log alert will be made and
will continue once daily afterward if the condition continues. The oldest items in the
dumpster will be deleted to make room for new dumpster data.
Poison Mailbox Detection and Correction
Exchange Server introduced poison message detection, placing messages that cause
issues with the transport service in a queue and allowing the transport service to continue
processing other messages. Exchange Server 2010 applies this same concept to mailboxes.
In some cases a single mailbox with corrupt data caused the Exchange Store to crash or even
Mailbox Services
to crash repeatedly. With poison mailbox detection the Exchange information store is able to
detect and then isolate the poison mailboxes.
A mailbox will be tagged as a potential threat if:
A mailbox has had more than five threads running that have not made progress for
60 seconds; or
A mailbox has a thread doing work that crashes.
When a mailbox meets either of these criteria, an entry in the registry is made for the
database along with the number of times the problem has occurred. Storing this information
in the registry allows this information to be replicated to other servers in the DAG by the
Windows Cluster service. This allows this information to be preserved during a failover. This
information is stored in the following locations in the registry:
HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\
Private-{Database GUID}\QuarantinedMailboxes\{Mailbox GUID}\Crash Count
HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\
Private-{Database GUID}\QuarantinedMailboxes\{Mailbox GUID}\\LastCrashTime
The default settings can be adjusted for how many crashes lead to quarantining a mailbox
as well as how long a mailbox should stay quarantined are stored. You can adjust these
settings by modifying the following registry keys:
HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private{Database GUID}\QuarantinedMailboxes\MailboxQuarantineCrashThreshold The
default setting for this key is three crashes.
HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private{Database GUID}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds The
default setting for this is 21,600 or six hours.
The Exchange information store will also keep information on when the mailbox was
flagged as a poison mailbox. When a database is brought online and periodically thereafter,
the information store reads the time that the mailboxes were identified as potential threats. If
the mailbox was quarantined more than two hours prior, the registry key for the mailbox will
be wiped out.
After a mailbox is flagged and quarantined, no access is allowed to the mailbox by any end
users or any of the Exchange processes. If the mailbox hasn’t caused any crashes in the last
two hours and is not quarantined, the registry path for the mailbox will be cleaned up by the
information store. If a mailbox has been quarantined for longer than the MailboxQuarantine
DurationInSeconds since the last time it caused a crash, it will automatically be removed from
quarantine. If the problematic mailbox has been fixed, the mailbox can also be removed from
quarantine manually by deleting the registry key and then remounting the affected database.
To be sure to keep ahead of any impending issues, you should monitor these registry keys
to ensure that there is not a systemic problem causing multiple mailboxes and databases to
become corrupt. This will also allow administrators to track down any issues and fix them.
Exchange Mailbox Services Configuration
Client Configuration
A variety of clients are able to connect to Exchange Server 2010. Other than receiving e-mail,
the client’s activity is the largest driving factor on how a mailbox server performs. A number
of things should be done to improve performance and protect the mailbox services.
In Office Outlook 2003, a new feature was introduced called Cached Exchange Mode.
This was different than offline mode, available in previous versions. Offline mode provided
a way for portable computers to synchronize data and then be able to work offline. Cached
Exchange Mode solved the same problem offline mode did; however, it also reduced the
bandwidth requirements between the client and Exchange server for clients that were
connected to the server. This allows users access to the local copy of the messages stored in
a OST file very quickly and synchronize the changes between the server and the client. This
reduced the I/O and bandwidth (after the initial synchronization) by up to 20 percent, a great
way to deploy Outlook in most situations.
For Outlook 2007 clients, ensure that the February 2009 cumulative update
for Outlook 2007 Service Pack 1 or later has been deployed to provide the best
Cached Exchange Mode does not work well in just a couple of situations. If a mailbox
is 100 MB, that data is stored locally and then synchronized as changes are made. As the
mailbox size grows, more resources are needed on the client to cache and synchronize the
data. On older clients that do not have enough drive space to index and manage the amount
of e-mail in a mailbox, large mailboxes may perform poorly, even if the mailbox server is not
performing poorly. It could be that additional resources should be planned for clients with
large mailboxes that will use Cached Exchange Mode. When you deploy client computers
that are running Outlook in Cached Exchange Mode, consider the following performance
improvement guidelines:
Ensure that the February 2009 cumulative update for Outlook 2007 Service Pack 1 or
later has been deployed. This update included a new OST schema which reduces I/O
requirements. Outlook 2010 also includes these performance improvements. For more
information about the update for Outlook 2007, read the Knowledge Base article at
For mailboxes up to 5 GB, most client computers capable of running Outlook 2007 or
higher should perform well.
For mailboxes larger than 5 GB and up to 10 GB, additional hardware may be required.
This will often be limited by disk I/O and the amount of memory. Using a RAID10,
solid-state disks, and faster traditional hard drives for storage of the OST file will
greatly improve performance.
For mailboxes with more than 10 GB, additional hardware and memory will be needed.
Archived data should be moved to an online archive and is thus exempt from being
cached locally.
Mailbox Services
For mailboxes that have more than 100,000 items in a single folder, views other than
Arranged By: Date may be slower.
Limit the amount of data that is available in the cache. By using the filter options
available on each folder, the amount of data that is cached on the local computer
can be limited. A typical example of this might be to only cache data that is less than
a year old.
For more information on optimizing Outlook performance, see the Knowledge Base article
KB640226 located at
Up until Outlook 2010, one of the other places where Cached Exchange Mode is not
supported is when Outlook is hosted on Remote Desktop Services (RDS), formerly known
as Terminal Services. In RDS multiple servers will be logged on to a single server accessing
Outlook, sending and receiving e-mail. The best practice in deploying RDS for high
availability is to use roaming profiles and to not store the user’s data on each RDS server in
the farm. RDS is deployed in the datacenter so that it can be managed by the IT staff. The
users that access the RDS may be located in other locations or have limited bandwidth, which
is a good reason to have Outlook run in the datacenter. The RDS servers are typically located
near the Exchange servers; RDS users don’t usually store data on each server. Therefore, if
you’re using an OST to synchronize data—especially if each time the user logged in Outlook
had to cache all of the mailbox data—it is understandable why using Cached Exchange Mode
is not recommended nor is it supported in that configuration.
Using Cached Exchange Mode performance can be limited by the local hardware. When
using Online Exchange Mode, the client requests information directly from the server. In
Exchange Server 2010 using Outlook in Online Mode or Outlook Web App, the guideline
is to limit the number of items in each folder to fewer than 100,000 provided there are
no third-party applications installed that index e-mail content. This is a huge jump from
Exchange 2007 SP2 where the guideline was a maximum of 20,000 items for Inbox and Sent
folders and 5,000 for Calendar and Contacts folders.
Many Outlook add-ins and desktop search software will add additional load to the client
and the mailbox server if they perform indexing or data mining. Providing end users with
guidance on software that they should avoid or using permissions and policy to restrict users
from installing these applications helps to reduce the likelihood that these applications can
negatively impact performance.
Configuring Public Folders
Public folders have received a lot of attention for the last two releases of Exchange Server.
The rumors of the removal of public folders in Exchange Server 2007 caused an uproar in the
messaging community. The fact is that public folders are still supported in Exchange Server
2007 as well as Exchange 2010, and there is good reason for the feature’s continued existence
as it still fills a need that in some cases is not easily solved by other solutions such as Microsoft
Office SharePoint Server or InfoPath. As Table 6-6 shows, in a number of scenarios public
folders still provide a viable solution.
Exchange Mailbox Services Configuration
TABLE 6-6 Deciding to Deploy Public Folders
Calendar Sharing
No need to move
Use either
Contact Sharing
No need to move
Use either
Custom Applications
Consider SharePoint
Consider SharePoint
Discussion Forum
No need to move
Use either
Distribution Group Archive
No need to move
Use either
Document Sharing
Consider SharePoint
Deploy SharePoint
Organizational Forms
No need to move
Use InfoPath
One of the current solutions that SharePoint Server does not fill is that of a multiple-master
document share, where document repositories can be replicated to multiple sites to provide
access to data at remote sites.
In Exchange Server 2010 public folders support and features have not changed appreciably
since Exchange Server 2007 SP1. Despite being a great solution for many client use cases,
public folders still remain complex to manage in large environments and complex to recover
from when problems arise without third-party tools. One of the only improvements made
in Exchange Server 2010 with regard to public folders is that they can now be placed on
multiple servers that are in a high-availability configuration, whereas before they were only
supported on a single high-availability–configured server and its copy. This may now reduce
the number of servers that are deployed because a dedicated public folder server is no longer
The choice to use public folders most likely means that either the application requirements
are not met by another technology or the company use of public folders is so innate that the
migration will take a number of years to complete. It is still important to bear in mind that
public folders as they exist today will eventually cease to exist. A new large deployment of
public folders should be very carefully scrutinized as to whether it is the best solution.
To understand where public folder replicas need to be placed, it is important to remember
how clients find and access replicas. When a user connects with Outlook or Outlook Web App
to a public folder the following occurs:
The default public folder database for the user’s account is always the initial target for
all requests. If there is a replica available in that public folder, Exchange Server directs
the client to this database for the public folder contents.
If a replica is not in the user’s default public folder database, Exchange Server redirects
the client to the least-cost Active Directory site that stores the public folder database.
The Active Directory site must include a computer that is running Exchange Server
2010 or Exchange Server 2007.
Mailbox Services
If no computer running Exchange Server 2010 or Exchange Server 2007 in the local
Active Directory site has a replica of the public folder, Exchange Server redirects the
client to the Active Directory site with the lowest-cost site link that does have a copy of
the public folder contents.
If no computer running Exchange Server 2010 or Exchange Server 2007 has a copy of
the public folder contents, Exchange Server redirects the client to a computer running
Exchange Server 2003 that has a replica of the public folder contents, using the cost
assigned to the routing group connector(s). This behavior, however, is not the default—
to allow public folder referrals across the routing group connector the properties of
the routing group connector must be modified.
If no public folder replica exists on the local Active Directory site, a remote Active
Directory site, or on a computer running Exchange Server 2003, the client cannot
access the contents of the requested public folder.
Figure 6-10 shows how Exchange Server uses Active Directory sites to provide clients
with the closest replica of a public folder for a public folder that is not available in the user’s
default public folder database.
Public Folder Server
FIGURE 6-10 Connecting to the closest public folder replica
Configuring public folder replicas requires that a detailed Active Directory site topology is
understood as well as the methods and locations that the public folder data will be accessed
Exchange Mailbox Services Configuration
from. A number of methods are chosen for creating replicas for public folders. The primary
goal is to keep as few replicas for each folder while maintaining the appropriate access
and redundancy.
Configuring Public Folders for Site Redundancy
As an example, let’s look at how Fabrikam uses public folders. A special project team located
in the Fresno office uses a set of public folders to store information about their project.
Because all of the users are located locally, there is no need to create a replica of the project
folders offsite. However, to ensure that data is not lost in the case of a local server failure,
at least one offsite replica should be created.
Often, especially when users are allowed to create public folders, replicas are not
created when a new folder is created. This leaves database backups a primary recovery
point for data in these public folders in case of a server failure. Create and schedule an
Exchange Management Shell script to periodically report on any public folders that only
have one replica.
Configuring Public Folders for Distributed Access
Another example of how public folders can be used can be seen at Litware. Rather than
employing SharePoint at this time, the HR department uses a public folder to distribute
documentation to all employees for review. This documentation does not change often;
however, it is used by all employees on a regular basis. In this case a replica of the public
folder should be created at each location so that employees have quick access to these files.
Creating a large number of replicas will increase the amount of data that needs
to be replicated to each server. This may affect the available bandwidth between sites.
Care should also be taken when adding replicas so as not to add too many at a single
time, which will reduce or eliminate the bandwidth required to transfer more important
messages or other critical business functions.
Designing Public Folder Deployments
In environments where public folders are heavily used, it is a best practice to deploy
dedicated public folder servers. This allows for dedicating CPU, memory, and disk resources
to isolated server functions, reducing the likelihood of resource contention.
It is also beneficial to have fewer larger public folder databases, rather than having smaller
public folder databases. This scales well and is more easily managed and monitored than
having several smaller public folder databases. This also reduces the amount of replication
traffic that must occur. As with many best practices, it still requires that adjustments
be made to fit each environment. As the public folder configuration is designed, the
Mailbox Services
number of databases needed to be deployed must be balanced by the cost of replication
traffic and against the costs of management complexity, database backup, maintenance,
and restore times.
Another factor to consider is the hierarchy of the public folders. As a general rule, because
of how replication is structured it is best to have more nested folders rather than having
more folders at the root of the hierarchy. When designing the hierarchy it is also important to
consider the permissions that will be granted on the folders. The goal should be to simplify
administration and reduce complexity as much as possible when assigning permissions. It
is good to have the folders that will have the least restrictive permissions toward the top of
the hierarchy, with the folders that require more restrictive permissions to the bottom. Often
enterprises will create root folders for each business unit or region and allow departments
and project folders to be created below the root folders. However, it is best not to have more
than 250 subfolders in each folder.
Additional Resources
Optimizing Outlook 2007 Cache Mode Performance for Very Large Mailboxes:
How to Troubleshoot Performance Issues in Outlook 2007:
Wikipedia: B+ Tree Structures:
Exchange 2010 Mailbox Server Role Requirements Calculator: http://msexchangeteam
Additional Resources
Edge Transport
and Messaging Security
Implementing Edge Transport Server 297
Planning for Anti-Spam 313
Antivirus Considerations
Planning for Messaging Security
he Edge Transport server role is designed to be placed directly in a perimeter
network, exposed to the Internet. Placing a server directly in the Internet can be the
cause of numerous security concerns. This chapter describes how to plan for and deploy
a Microsoft Exchange Server 2010 Edge Transport server role and the security issues
related to the deployment.
This chapter also describes how to configure secure Simple Mail Transfer Protocol
(SMTP) messaging as well as Domain Security, a feature available in Exchange
Server 2007 and later versions. The Edge Transport role provides powerful anti-spam
functionalities, and some antivirus features. Because the Edge Transport role does not
include a virus scanner, you can integrate additional antivirus products such as Microsoft
Forefront Protection 2010 for Exchange Server.
Implementing Edge Transport Server
The Edge Transport server role in Exchange Server 2010 provides a secure SMTP gateway
for all incoming and outgoing e-mail in an organization. As an SMTP gateway, the Edge
Transport server’s primary role is to maintain message hygiene, which includes anti-spam
and antivirus filtering. You also can use the Edge Transport server to apply messaging
policies to messages that are sent to the Internet.
When planning to deploy Edge Transport servers, consider the following factors:
You cannot install the Edge Transport server role along with any other Exchange
Server 2010 server role. The Edge Transport functions require a very separate level
of security and must be separated from your Exchange organization. To provide
increased security, you must install the Edge Transport server role on a separate
computer, which can be virtual or physical.
Edge Transport servers should be installed in the perimeter network and should be
physically secure and well separated from servers in the internal network.
The computer should not be a member of an internal Active Directory domain.
NOTE You should not install the Edge Transport server role on a computer
that is a member of the internal Active Directory domain, but you can install it
in a perimeter Active Directory forest. Microsoft IT and other large companies have
a dedicated Active Directory domain for servers in the perimeter network. This
makes security updates and other maintenance/management easier than when
you’re dealing with non-domain-joined computers.
Considering Firewall Ports
Because the Edge Transport server role is installed in a perimeter network and thus is directly
connected to the Internet, you should also plan to place a firewall between the Internet and
your Edge Transport server to increase protection. This firewall should be configured to open
certain ports.
This section is about what network ports you should open in the firewall that is between
the Internet and the perimeter network (external) and the perimeter network and the internal
corporate LAN (internal), as described in Table 7-1. You can take this as the minimum number
of ports you should open, but remember that you can also configure the Edge Transport to
use network ports other than those listed here.
The table includes only the Edge Transport server role. A list of firewall ports for all server
roles can be found in Chapter 3, “Exchange Environmental Considerations.”
TABLE 7-1 Firewall Ports Required for Edge Transport Server Role
Allow port 25 from all
external IP addresses to
the Edge Transport server.
Enables SMTP hosts on
the Internet to send SMTP
messages to this server.
Allow port 25 to all external
IP addresses from the Edge
Transport server.
Enables the Edge Transport
server to send SMTP
messages to the Internet.
Allow port 53 to all external
IP addresses from the Edge
Transport server.
Enables the server to resolve
Domain Name System (DNS)
names on the Internet.
Allow port 25 from the Edge
Transport server to specified
Hub Transport servers.
Enables the transmission of
inbound SMTP messages
onward to internal Hub
Transport servers.
Edge Transport and Messaging Security
Allow port 25 from specified
Hub Transport servers to the
Edge Transport server.
Enables the transmission of
outbound SMTP messages
from internal Hub Transport
to the Edge Transport server.
Allow port 50636 for secure
Lightweight Directory
Access Protocol (LDAP) from
Hub Transport servers that
participate in EdgeSync to
the Edge Transport server.
Enables the Hub Transport
server to replicate directory
information to the Edge
Transport servers using Edge
Allow port 3389 for Remote
Desktop Protocol (RDP) from
the internal network to the
Edge Transport server.
Enables remote desktop
administration of the Edge
Transport server
Edge Transport Role and Forefront TMG
Henrik Walther
Technology Architect, Timengo Consulting, Copenhagen Denmark
icrosoft Forefront Threat Management Gateway (TMG), Microsoft’s
application layer firewall solution, and Exchange 2010 Edge Transport role
can now be installed together on the same computer. This is especially an attractive
configuration for SMORGs (small and medium organizations) that are bound by
a limited IT budget. Even though Microsoft ISA 2006 is supported with Exchange
2010, Microsoft recommends using Forefront TMG to prevent configuration
issues. You also cannot install Edge Transport and Microsoft ISA 2006 on the same
computer because ISA 2006 does not support 64-bit operating systems.
If you plan to use Microsoft ISA or Forefront TMG to separate Edge Transport and
Hub Transport server roles, you need to remember either to add Exchange SMTP verb
commands to the SMTP add-in filter or to disable the filter altogether. You can find
the details at
Planning and Configuring Edge Synchronization
The Edge Transport server does not use Active Directory to store its configuration
information; instead, Edge Transport servers use Active Directory Lightweight Directory
Services (AD LDS) to store this data. AD LDS is the successor of Active Directory Application
Mode (ADAM), a service that was available in Windows Server 2003.
Implementing Edge Transport Server
About AD LDS
AD LDS is a special mode of the AD DS that stores information for directory-enabled
applications. AD LDS is an LDAP-compatible directory service that runs on servers running
the Windows Server 2008 or Windows Server 2008 R2 operating system. AD LDS is designed
to be a stand-alone directory service. It does not require the deployment of DNS, domains,
or domain controllers; instead, it stores and replicates only application-related information.
Before you can install the Edge Transport server role, you must install the AD LDS server
role on the same Windows Server 2008 computer that will host the Edge Transport role.
This is because AD LDS stores configuration data for your Edge Transport server role. During
Exchange installation, AD LDS is then configured automatically. The following types of
information are stored in AD LDS:
Recipient information
The AD LDS database is stored in the <Exchange_Install_Path>\TransportRoles\data\Adam
directory. Similar to the queue database as described in Chapter 5, “Routing and Transport,”
the AD LDS service also uses the Extensible Storage Engine (ESE) database engine, so the files
that are used for its database are comparable to other ESE databases such as queue databases
or mailbox databases.
The AD LDS stores configuration and recipient information. The Queue
database also exists on every Edge Transport to store message queues.
The AD LDS instance does not need much administration because all the information that
it contains is synchronized using Edge synchronization from the Active Directory instance
that holds all of the Exchange organizational configuration data and information about
mail-enabled objects. Even if the database is lost, you just start EdgeSync again and the
database will be newly created.
However, always consider that the database does not include all configurations
and settings, so it is best practice to back up the Edge server configuration using the
ExportEdgeConfig.ps1 script.
Edge Synchronization
Edge synchronization, or EdgeSync, is a process that replicates information from your internal
Active Directory to the AD LDS located on the Edge Transport server.
Because Edge Transport servers are not joined to the internal Active Directory domain, they
cannot directly access the configuration or recipient information that is stored in Active Directory.
You can deploy Edge Transport servers without using EdgeSync, but using EdgeSync
can decrease the effort needed to administer the Edge Transport servers. Active Directory
contains much of the configuration information required by the Edge Transport server.
For example, if you configure accepted domains in Exchange Management Console for all
Hub Transport servers centrally, these accepted domains are replicated automatically using
Edge Transport and Messaging Security
EdgeSync to the Edge Transport servers. Every Edge Transport server needs its own Edge
Subscription to synchronize with Active Directory.
To enable any filtering or transport rules that are based on recipients, you must implement
EdgeSync to replicate the recipient information to AD LDS.
After you enable Edge Synchronization, the EdgeSync process establishes a point of
synchronization between one Hub Transport server in the Active Directory site that was
selected and the Edge Transport server, and synchronizes configuration and recipient
information between Active Directory and AD LDS.
Even though EdgeSync is very similar to Exchange Server 2007, in Exchange 2010
EdgeSync keeps track of synchronized information and only synchronizes the changes since the
last replication cycle. Of course, this is much more efficient than EdgeSync in Exchange 2007.
Only the internal Hub Transport servers, not the Edge Transport servers, initiate
EdgeSync replication. EdgeSync replication traffic is always encrypted using Secure LDAP.
During synchronization, EdgeSync replicates the following data:
Accepted domains
Send connectors
Hub Transport servers list (for dynamic connector generation)
Recipients (one-way hashed)
Safe senders, safe recipients, and blocked senders (one-way hashed)
Domain Secure List (such as the TLSSendDomainSecureList and
TLSReceiveDomainSecureList properties)
All options that are synchronized by EdgeSync are managed in Active Directory, so
you can no longer change them on the Edge Transport server. You need to change them
using EMC or EMS connected to your internal Exchange organization and allow EdgeSync
to transfer the configuration settings to the Edge Transport servers.
Some configuration settings have to be made on the Edge Transport server role level
because these configurations are not replicated using EdgeSync. The following list includes
all areas that you need to configure for every Edge Transport server or use Edge Transport
cloning to share a single configuration between all Edge Transport servers:
All Edge Transport server settings (external or internal DNS Lookups, Log Settings,
Limits, and so on)
Exchange Product Key
Anti-spam settings
Receive connectors
Implementing Edge Transport Server
Transport rules
Digital Certificates and Exchange services enabling digital certificates to secure
To establish Edge Synchronization between an Edge Transport and Hub Transport server, you
need to follow these steps:
Create an Edge subscription file on Edge Transport.
Import an Edge subscription file on Hub Transport.
Start and verify the EdgeSync Process.
Create an Edge subscription file on Edge Transport
If you want to perform EdgeSync on your Edge Transport server, you should consider the
following areas before creating the Edge subscription file:
An Edge Transport server needs a fully qualified domain name (FQDN) configured.
You must register the FQDN with your DNS server.
The FQDN must be resolvable and reachable from the Hub Transport servers in the
site where you add the Edge subscription file.
EdgeSync and the Connectors use the computer certificate of the Edge Transport
server, so make sure you’ve already installed the correct certificate (for example, that
supports TLS if required).
The hub server must be able to communicate with the Edge Transport
server using the FQDN as defined in the Edge Subscription file! Remember, by default the
Firewall on the Edge Transport server refuses a PING response!
You create an Edge subscription file by using the New-EdgeSubscription cmdlet in EMS
started with Run as Administrator. The default EMS will not provide sufficient permissions to
create an edge subscription. This will create an XML file, as shown in Figure 7-1.
As you can see, the sample Edge subscription file includes certain information such as
the Edge servers’ FQDN, the Edge server’s public certificate, the default SSL port that is used
for AD LDS, and the server’s Exchange version. You have to use the Edge subscription file on
a Hub Transport server within 1,440 minutes or the XML will expire.
The Edge Transport server isn’t limited by version control (like Hub Transport or
UM server role), meaning you can subscribe an Exchange 2010 Edge Transport server to
an Exchange 2007 Hub Transport server just fine. You just won’t benefit from incremental
EdgeSync. You can also have an Exchange 2007 Edge Transport server in front of an
Exchange 2010 Hub Transport server.
Edge Transport and Messaging Security
FIGURE 7-1 Sample Edge subscription file
Import Edge subscription file on Hub Transport
After you create the Edge subscription file, you need to copy it to a Hub Transport in the
Active Directory site that you want to link the Edge Transport server to. On the Hub Transport
server, use the New-EdgeSubscription cmdlet to import the Edge subscription file.
Be aware that you cannot pass the filename directly to the cmdlet—you need to pass
the data string, as shown in Figure 7-2. This is because of remote Windows PowerShell.
Since the script is not running locally, you can’t give a local path but have to pass the file
data in the cmdlet.
FIGURE 7-2 Importing an Edge subscription file using EMS
Implementing Edge Transport Server
Start and Verify the EdgeSync Process
After the Edge subscription file is imported to the Exchange configuration, the EdgeSync
replication process starts automatically. The default port for synchronization is port 50636
as defined in the Edge subscription file.
To change the default EdgeSync communication port you can use the ConfigureAdam.ps1
script located in the <Exchange_Install_Path>\Scripts folder. For example, if you want to change
the communication port to 50222, run .\ConfigureAdam.ps1 –Sslport:50222 with EMS.
The first Hub Transport in the Active Directory site where you created the Edge
subscription that notices the subscription seizes the lease and will use the Microsoft Exchange
EdgeSync service to start the synchronization with the Edge Transport server. This Hub
Transport server will keep the lease until it goes offline or is otherwise unable to service the
subscription which will then result in the next Hub Transport available in the Active Directory
site seizes the lease.
If you like to force immediate replication, you can use the Start-EdgeSynchronization –
TargetServer <EdgeTransportName> -Server <HubTransportName> cmdlet, which will trigger
the replication and show you some information about recent changes in Active Directory.
You can use the Windows LDP client to look at the AD LDS database on the Edge
Transport server by connecting to port 50389. Even though most entries are encrypted,
you can check that replication is working.
Alternatively you can make sure that the EdgeSync process finished successfully by
running the Test-EdgeSynchronization –FullCompareMode cmdlet on a Hub Transport server in
the connected Active Directory site that will compare Active Directory with the AD LDS on all
Edge servers that are subscribed to the Active Directory site to make sure they are synchronized
correctly. You will receive detailed information as output, as shown in Figure 7-3.
FIGURE 7-3 Running the Test-EdgeSynchronization cmdlet
Edge Transport Configurations
This section describes Edge Transport configurations that you should consider when planning
for this server role: cloned configuration, delivery status notifications, header firewall, and
address rewriting.
Edge Transport and Messaging Security
Edge Transport Cloned Configuration
Cloned configuration is the process of configuring multiple Edge Transport servers with identical
configurations. You can use the cloned configuration scripts provided as part of the Exchange
installation kit with EMS to duplicate the configuration of a source server to a target server.
Edge Transport servers do not support Windows Failover Clustering. A failover cluster
provides high availability by making application software and data available on several
servers that are linked together in a cluster configuration. But because failover clustering
is not available, to achieve high availability for messaging transport, you should implement
multiple Edge Transport servers.
Even though AD LDS supports directory replication, Exchange Server 2010 does
not provide an option to use directory replication for configuring multiple Edge Transport
servers. The only way to copy the configuration between the Edge Transport servers is
to use cloned configuration. This needs to be done whenever you do any configuration
changes to one of the servers.
You can use cloned configuration to ensure that all the Edge Transport servers have the
same configuration. You only configure one server, and export the configuration to an XML
file that is then imported to the target servers.
The XML file includes the following configuration information:
Transport server file paths and all log files paths (such as the Message Tracking log path)
Transport agents, including status and priority
All Send and Receive connector–related settings (including Send connector passwords
encrypted with a default encryption key)
Accepted Domain information
Anti-spam features and configuration settings
Don’t forget that any Transport Rule configured on the Edge Transport server is not
exported, so you need to export the rules with the Export-TransportRuleCollection cmdlet
and import them on the target Edge Transport servers.
Some settings are not cloned; however, they are synchronized by EdgeSync and therefore
only need to be considered in a configuration where EdgeSync is not used:
To configure cloned configuration, use the ExportEdgeConfig.ps1 and ImportEdgeConfig
.ps1 scripts located in the <Exchange_Install_Path>\Scripts folder to export configuration
information from one Edge Transport server to an identically configured Edge Transport server.
Implementing Edge Transport Server
You can also use the tool to test configuration changes and offer rollback assistance or to assist
in disaster recovery when you deploy a new Edge Transport server or replace a failed server.
To configure cloned configuration, follow these steps:
Use the ExportEdgeConfig.ps1 script to export the configuration information on the
source Edge Transport server.
Validate configuration and create an answer file using the ImportEdgeConfig.ps1
script on the target Edge Transport server. The answer file will contain entries for every
source server setting that is not valid for the target server.
Edit answer file and change all server-specific settings, such as the server name, to
reflect the target server settings.
Import configuration using the ImportEdgeConfig.ps1 script with the -IsImport $true
parameter to import the information from both the intermediate XML file and the
answer file on the target Edge Transport server.
When importing the configuration, depending if the target Edge Transport
configuration is part of Edge Synchronization or not, you may face error messages that
some settings, such as Accepted Domains, cannot be imported. This situation is normal
and can be ignored.
Delete the configuration and answer XML files to prevent retrieval of Send Connector
passwords (if used).
Understanding Header Firewall
Every Receive or Send connector adds information to the message it is transferring. This
information is available in the SMTP message header and includes information such as all
the servers that transferred that message and at what time. To prevent spoofing of such
information, Exchange 2010 includes a feature called Header Firewall that (if configured)
removes all additional information from inbound and outbound messages. But let’s first start
with an overview of the X-header fields. If you want to read more information about this
topic, you can access the Exchange 2010 Help file article “Understanding Header Firewall”
Exchange Server 2010 adds X-header fields to every message to transfer Exchange-internal
information. X-header fields are an unofficial but generally accepted way to add header fields
to a message.
The purpose of X-header fields is to transfer information about the message to the
other Transport servers. For example, a message is scanned by the Content Filter agent
only at the first Transport server, which adds the spam confidence level (SCL) rating to
the X-MS-Exchange-Organization-SCL field to the header of the message. All subsequent
Edge Transport and Messaging Security
Transport servers can then use this information and do not need to scan the message again.
In Figure 7-4 you see a message that contains various X-header fields by looking at the
Internet headers field in Microsoft Outlook.
FIGURE 7-4 Viewing X-headers in Outlook
To read the message headers correctly, it is important to understand their meaning.
Exchange Server 2010 includes several X-header fields and they are listed in Table 7-2.
TABLE 7-2 X-Header Fields Used by Exchange 2010
Lists all transport rules that processed this message.
Provides a summary report of the anti-spam filter
results that have been applied to the message by the
Content Filter agent. Detailed information can be
found on TechNet “Understanding Anti-Spam Stamps”
Specifies the authentication source. The possible values
are Anonymous, Internal, External, or Partner.
This field is only added when Domain Secure
authentication took place and includes the fully
qualified domain name (FQDN) of the remote
authenticated domain.
Implementing Edge Transport Server
Specifies the authentication mechanism for the
submission of the message as a two-digit hexadecimal
Specifies the FQDN of the server computer that
evaluated the authentication of the message on behalf
of the organization.
Identifies journal reports in transport.
Identifies the time when the message first entered the
Exchange organization.
Includes the original sender of a quarantined message.
Includes the original size of a quarantined message.
Includes the original SCL of a quarantined message.
Identifies the phishing confidence level. The possible
phishing confidence level values are 1 through 8.
Indicates that the message has been quarantined in
the spam quarantine mailbox and a delivery status
notification (DSN) has been sent. Alternatively, it
indicates that the message was quarantined and
released by the administrator.
Includes the SCL of the message. The possible SCL
values are 0 through 9. A larger value indicates a
suspicious message. The special value -1 means that
it is an internal message that is not processed by the
Content Filter agent.
Includes the results of the Sender ID agent. The
Sender ID agent uses the sender policy framework (SPF)
to compare the message’s source IP address to the
domain used in the sender’s e-mail address.
Includes the result of the Sender ID agent, especially
the Purported Responsible Domain (PRD). This is
the domain of the purported responsible address as
determined by the Sender ID agent.
Edge Transport and Messaging Security
Besides X-header fields, Header Firewall also controls Routing headers. Routing headers
include information about all messaging servers used to deliver the message.
In some situations you need to implement Header Firewall to prevent someone from creating
a message that will spoof X-headers and thereby imitate an Exchange Transport server in
order to have their messages accepted as legitimate by the receiving server. This is especially
crucial if your organization does not include a smart host that removes these headers.
Header Firewalls are configured by assigning Active Directory permissions on the
respective Send connector or Receive connector. A dedicated ExtendedRight attribute
and Deny permission is used to control enabling or disabling a Header Firewall. The following
principle applies:
If Deny is enabled (or True), the Header Firewall is turned on for the specified area and
headers are removed.
If Deny is disabled (or False), the Header Firewall is turned off and the headers are
preserved by the connector.
By default, no Send or Receive connector is configured for Header Firewall. In a situation
where you use an Edge Transport server, the X-header is overwritten anyway when a message
enters the organization. But for outbound messages, Routing headers might disclose too
much information about your company. For example, the name of any internal Hub Transport
server that processes the message is shown in the Routing header.
Several Extended Rights control Header Firewalls on Send connectors and Receive
connectors. Table 7-3 provides an overview of possible Extended Rights.
TABLE 7-3 Connectors and Extended Rights for X-Header Configuration
Receive connector
Configures Header Firewall on
“X-MS-Exchange-Forest . . .” headers
Configures Header Firewall on
“X-MS-Exchange-Organization . . .”
Configures Header Firewall on
“Resent- . . .” and “Received:” headers
Configures Header Firewall on
“X-MS-Exchange-Forest . . .” headers
Configures Header Firewall on
“X-MS-Exchange-Organization . . .”
Configures Header Firewall on
“Resent- . . .” and “Received:” headers
Send connector
Implementing Edge Transport Server
To configure Header Firewalls, you can either use EMS or directly access the Permissions
tab of the connector’s Advanced Security Settings using ADSIEdit, as shown in Figure 7-5.
You can see Advanced Security Settings of the Send connector on the Edge Transport server
that connects to the Internet. Because Deny is set for Anonymous Logon on Send Routing
Headers permission, all internal message servers are removed from the routing path.
FIGURE 7-5 Configuring Header Firewall using ADSIEdit
When using ADSIEdit in Active Directory to configure permissions, remember that you can
configure Edge Transport Receive connectors only directly on the Edge Transport server. Thus
you can only configure Send connectors using ADSIEdit in Active Directory, for configuring
Edge Transport Receive connectors you need to use EMS on the Edge Transport directly, as
Receive connectors are not synchronized to Active Directory with EdgeSync.
Configuring Header Firewall using EMS is not trivial—many groups are involved and you
have to configure the right group to turn Header Firewall on or off. The best approach is to
look at your existing connectors to identify the groups you need to configure. The following
cmdlet is an example to show you the Extended Rights of a Receive connector:
Get-ReceiveConnector <ReceiveConnectorName> | Get-ADPermission | ft user, deny,
To configure Header Firewall in your scenario you just need to change the permissions
on the respective Receive or Send connector. For example, let’s turn on Header Firewall for
Routing headers on the Send connector to the Internet for all non-authenticated target
servers. You can configure this using the following cmdlet on the Send connector that sends
messages to the Internet:
Add-ADPermission -id “<SendConnectorName>” -User “NT Authority\Anonymous
Logon” -ExtendedRights Ms-Exch-Send-Headers-Routing -Deny
Edge Transport and Messaging Security
Remember that after you configure the permissions, you need to restart the Microsoft
Exchange Transport service on all Hub Transport servers that are configured to use the Send
connector so that Header Firewall will take immediate effect.
You can verify whether Header Firewall is turned on by enabling verbose logging on
the Receive connector in EMC or using the ProtocolLoggingLevel Verbose parameter in the
Set-ReceiveConnector cmdlet. You will now receive a detailed protocol log in the <Exchange_
Install_Path>\TransportRoles\Logs\ProtocolLog\SMTPReceive folder. In the current log file,
you will find the following entries for each SMTP session that has Header Firewall turned off:
For every entry that’s missing, Header Firewall is enabled!
Make Sure Edge and Hub Authenticate Correctly
Christian Schindler
Senior Consultant, NTx BackOffice Consulting Group, Austria
ne of my customers once had an issue where inbound mail delivery from Edge
Transport to Hub Transport was working correctly, but anti-spam—although
correctly configured—didn’t work as expected: X-AntiSpam- and Antivirus-Headers
(SCL, SenderID, and so on) weren’t part of the message header when the message
reached Outlook.
After digging into the issue, I finally discovered that authentication methods
between the Edge and Hub Transport server were modified from the default
settings. I re-enabled Exchange Server authentication on the connectors, which
fixed the issue.
So why is authentication between Edge and Hub Transport important in my
scenario? Because Exchange only accepts X-AntiSpam- and AntiVirus-Headers
through authenticated SMTP Sessions. This makes it nearly impossible for spammers
or hackers to send fake X-AntiSpam or X-Antivirus Headers.
For most scenarios, especially if you use Edge Transport servers, you do not need to change
Header Firewall settings—their default configuration is sufficient for most scenarios. However,
if you do not use Edge Transport servers, you should enable Header Firewall for the Receive
connector and Send connector to the Internet.
Implementing Edge Transport Server
In the Contoso scenario, the Hub Transport server receives messages from a smart host
from the Internet. To prevent spoofing of X-headers it is best practice to configure your
Receive connector that receives the messages from the Internet to enable Header Firewall.
This is done using the following cmdlet:
Add-ADPermission -id <ReceiveConnectorName> -User "NT Authority\Anonymous Logon"
-ExtendedRights ms-Exch-Accept-Headers-Organization -Deny
Figure 7-6 shows you the header configuration as performed through EMS for X-headers
Organization and the command to verify that the permission was configured correctly. As
seen in the figure, only the ms-Exch-Accept-Headers-Organization has a Deny permission
configured; thus only this X-header has Header Firewall turned on.
FIGURE 7-6 Configuring Header Firewall configuration in EMS
Configure Address Rewriting
Edge Transport servers include Transport agents that allow you to modify e-mail addresses
for inbound or outbound messages. This process is called address rewriting.
Two Transport agents provide the capability for address rewriting: Address Rewriting
Inbound agent and Address Rewriting Outbound agent. They should be enabled for address
rewriting to work correctly.
But why do address rewriting? You need to implement it for several reasons, including the
Group consolidation or Partners This is when your company includes several
groups that have separate e-mail addresses internally. For example, you have a group
that uses the e-mail address but your company wants to move to
a single e-mail address and thus replace all messages with the originator of @sales with
Mergers and acquisitions This situation occurs when your company purchases
a new company that is running in a separate messaging system. For this situation all
messages get rewritten to a common e-mail address. For example, Fabrikam purchases
Contoso, and because they should use the Fabrikam e-mail address, they rewrite every address into
Edge Transport and Messaging Security
Address rewriting will replace the e-mail addresses of messages. You have to make
sure that the properties of the recipient mailboxes include the replaced e-mail address in
their proxy addresses; otherwise a reply will receive an NDR.
In some situations—for example, signed, encrypted, or rights-protected messages—you
cannot change an e-mail address because that would, for example, make a signed message
invalid. The address rewriting agent thus will not change the message in any way as it would
make the message unreadable.
Using address rewriting can break your federating calendaring requests
because the domain name is changed. If you use address rewriting and you want to
implement federated sharing, ensure that all domains involved in the address rewriting are
defined in your federated organization identifier. For more information see Chapter 10,
“Federated Sharing.”
Address rewriting is configured using the Exchange Management Shell (EMS); you cannot
configure address rewriting in the Exchange Management Console.
You configure address rewriting using the New-AddressRewriteEnty cmdlet. You can
configure address rewriting in the following ways:
Rewrite a single e-mail address, one domain, or a domain including all its subdomains.
Rewrite addresses on either inbound and outbound messages or just outbound
Let’s go back to our scenario where Fabrikam buys Contoso. Contoso’s Exchange
organization is currently not your responsibility, but every message they sent to the Internet
is transported over Fabrikam’s Edge Transport servers. You want to make sure that every
outbound e-mail address is replaced with So first you have to
make sure that every Contoso recipient exists in the Fabrikam Exchange organization with
an e-mail address that matches both their and the address.
Additionally there must be a Send connector to forward messages for Contoso users
(addressed with their mail address) to the Contoso Exchange organization.
If that’s guaranteed, you can use the following cmdlet on your Edge Transport servers to
enable address rewriting:
New-AddressRewriteEntry -Name "Contoso to Fabrikam" -InternalAddress
-ExternalAddress -OutboundOnly $true
Planning for Anti-Spam
Planning for anti-spam to reduce the massive number of spam messages that circulate
nowadays through the Internet has become one of the most important tasks of message
administrators. Unfortunately, spammers and malicious senders use a variety of techniques to
send unwanted messages to your organization. No single tool or process can eliminate all spam.
Planning for Anti-Spam
By default the anti-spam agents are installed only on the Edge Transport server role.
However, they can also be enabled on Hub Transport servers where needed.
Any change to the anti-spam agents is immediately activated. If, for
example, you add an IP address to an IP Block List, it is immediately blocked without any
service restart.
How Exchange 2010 Does Spam Filtering
Exchange 2010 includes a variety of anti-spam features designed to work cumulatively to
reduce the amount of spam messages that enter your organization. This is done by using
spam-filtering agents to examine each SMTP connection and each message sent through it.
As illustrated in Figure 7-7, the sequence of spam agents that will inspect a connection or
message is defined carefully.
Exchange Server 2010
Edge Transport server
IP Allow List
IP Block List
Sender Filtering
Sender ID
Outlook Safe
Senders List
Exceed SCL
Below SCL
FIGURE 7-7 SPAM agent filtering sequence
When an SMTP server on the Internet connects to the Edge Transport server and initiates
an SMTP session, the Edge Transport server examines each message using the following
When the SMTP session is initiated, the Transport server applies connection filtering
using the following criteria:
IP Allow list and IP Allow List Provider
Edge Transport and Messaging Security
IP Block list
Real-time block list (RBL) of any IP Block List Provider
The Transport server compares the sender’s e-mail address with the list of senders
configured in sender filtering.
The Transport server examines the recipient against the Recipient Block list configured
in recipient filtering.
Exchange Server 2010 applies Sender ID filtering. Depending on how the Sender ID
filtering is configured, the agent might delete, reject, or accept the message that
failed Sender ID validation. If the message is accepted, the server adds the Sender
ID validation stamp to the message properties. Although incremental, the failed
Sender ID status is included as one of the criteria when content filtering processes the
The Edge Transport server applies content filtering and performs one of the following
Content filter compares the purported sender to the list of senders in the
per-recipient Safelists aggregated from Microsoft Office Outlook users. If the
sender is on the recipient’s Safe Senders List, the message is assigned a spam
confidence level (SCL) rating of -1, excluded from further anti-spam processing,
and after antivirus scanning delivered directly to the end user’s Inbox richly
rendered. If the sender is not on the recipient’s Safe Senders List, the message is
scanned and assigned an SCL rating.
If the SCL rating is higher than one of the configured SCL thresholds, a content
filtering agent takes the appropriate action of deleting, rejecting, or quarantining
the message.
If the SCL rating is lower than one of the SCL thresholds, the message is assigned
an appropriate SCL verdict and delivered to the Mailbox server, which decides
where to deposit the message based on the recipient’s mailbox settings.
The message can end up either in the Junk E-mail folder or in the Inbox.
How Anti-Spam Updates Work
Spam is changing continuously, so Exchange 2010 also includes an automatic anti-spam
update service that handles content filter updates. This service requires your Transport
server to have either direct Internet access, Web access using a proxy, or a Windows
Update Service (WUS). Anti-spam updates can be configured in two different types:
manual or automatic.
Manual updates only include Content Filter updates but do not require additional licenses;
automatic updates also include Content Filter and add Spam Signature and IPReputation
updates. However, automatic updates require an Enterprise Client Access License (E-CAL) that
needs to be purchased for every mailbox in your organization.
Manual Content Filter updates will be downloaded and installed when the update is
made available by Microsoft; this is commonly done on a biweekly basis. Thus you can only
Planning for Anti-Spam
describe this anti-spam protection as being very basic—more suitable for small organizations.
You should consider purchasing E-CALs for automatic updates which provide multiple
anti-spam updates per day if you’re planning for a larger company. E-CALs also include the
required licenses for Forefront Protection 2010 for Exchange Server (FPE 2010), which you can
optionally deploy to add an extra level of protection for anti-spam.
You configure the anti-spam update service using the Enable-AntispamUpdates
cmdlet and receive information on what pattern versions are installed using the
Get-AntispamUpdates cmdlet as shown in Figure 7-8.
FIGURE 7-8 Configuring automatic anti-spam updates
You can see that multiple update patterns are available in the anti-spam update of
Exchange 2010. Table 7-4 lists all available pattern updates.
TABLE 7-4 Anti-Spam Pattern Updates
Content Filter
Content Filter updates. The filter is based on Microsoft’s
SmartScreen technology and is used for scanning the
body of the messages and assigning SCL ratings.
Spam Signature
(E-CAL required)
Identifies the most recent spam campaigns.
IP Reputation
(E-CAL required)
Provides sender reputation information about
IP addresses that are known to send spam.
All patterns are part of a single update process—no separate processes are required.
Anti-Spam with Forefront Protection 2010 for Exchange
Alexander Nikolayev
Program Manager, Forefront Server Security, Microsoft Corporation
t Microsoft, we use Forefront Protection 2010 for Exchange (FPE) for anti-spam.
If you use FPE 2010, you might consider these three best practices for enabling
the most effective anti-spam defense.
Edge Transport and Messaging Security
First, where will you reject spam? The most efficient FPE positioning is to scan
the messaging stream at the entry point into Exchange organization. An early
rejection of unwanted e-mail will prevent wasted resources to push unnecessary
payloads through the network and save some bandwidth. Best hygiene practices
call not only for physical positioning of FPE on the perimeter of the organization’s
network but also to enable early rejection of spam inside the FPE, which is a layered
anti-spam solution. The first layer, Connection Filtering, is based on new Forefront
DNSBL technology. When enabled, our testing shows that Forefront DNSBL will
reject around 90 percent of spam based on the connecting IP address even before
it begins to examine the content of the message. Forefront aggregates RBL feeds
from multiple vendors, and the DNSBL feature is configuration-free, so it’s not only
very effective but also simple to use.
Second, what messages will you reject? One person’s ceiling is another person’s
floor, right? What is considered as spam by some recipients is legitimate mail
to others. To help FPE figure out for whom to reject and for whom to accept a
given piece of mail, it is important to enable recipients’ Outlook Safe/Block Lists
aggregation. The FPE Content Filter, based on Cloudmark CMAE engine, will
take these lists into consideration on a per-recipient basis to provide the desired
granularity level. Using the default SCL settings on the content filter will reject the
rest of spam; however, if you need to relax the filter you can lower SCL thresholds to
quarantine questionable mail for triaging.
And finally, where to triage? Previously, Microsoft recommended quarantining
questionable e-mail in a dedicated Exchange mailbox so that an administrator could
access, review, retrieve, and resend false positives. This was not always an easy task
because of the volume of quarantined messages. Forefront makes triaging easier
because the messages by default are stored in Forefront quarantine. However, with
the volume of quarantined messages now drastically reduced, it makes sense to
review our default approach to triaging and perhaps allow these messages to be
deposited into a recipient’s Junk Mail folders. The amount of suspected spam is very
small. For example, based on internal Microsoft data, only about 50 messages per
1 million of external mail submissions are quarantined. To determine the volume
of quarantined mail, run the Get-FseSpamReport cmdlet and look for the number
of messages with SCLs between five and eight inclusive—these are the messages
that will be quarantined by default. If you see that the amount is small, maybe it’s
time to entrust your recipients with the responsibility of triaging suspected spam,
considering that they will get only a couple of such messages per month.
In addition, do not forget to enable Backscatter filtering. Backscatter filtering will protect
your organization from bogus NDRs to recipients who never sent the NDR mail in the first
place. This happens when a malicious user spoofs the MAIL FROM address as someone from
your organization; the receiving server might generate an NDR back to an unsuspecting
victim. For the filter to work correctly you need to have the same set of keys installed on
every transport server that participates in sending to or receiving mail from the Internet.
Planning for Anti-Spam
Enable Anti-Spam on Hub Transport Servers
Even though it is not enabled by default, you can also enable anti-spam on Hub Transport
servers. This is especially a good idea if your Hub Transport server connects Exchange to
a smart host that handles inbound Internet traffic for a company. Many companies deploy
UNIX- or Linux-based servers in this role, so you can provide another, different layer of
anti-spam if you enable it on the Hub Transport servers.
You enable the anti-spam features by running the Install-AntispamAgents.ps1 script
available in the <Exchange_Install_Path>\Scripts folder. After running the script you need to
restart the Microsoft Exchange Transport service to make sure the changes are applied.
For anti-spam features to work correctly, you must have at least one
IP address of an internal SMTP server set on the InternalSMTPServers parameter on
the Set-TransportConfig cmdlet. If you only have one Hub Transport server in your
organization, enter the IP address of that computer.
Connection Filtering
Connection filtering inspects the IP address of the remote server that is trying to send the
message to determine what action to take on an inbound message. If a specific server is
found on the IP Allow list or on the list of an IP Allow list provider, the message is not scanned
anymore but directly marked as not spam. Similar to the IP Allow list, an IP Block list also
exists that consists of servers that are not allowed to send messages because they have been
identified as spam senders. The following sections discuss IP Allow lists and IP Block lists as
well as list providers.
It might seem obvious, but if your Exchange organization receives all
messages from a smart host server, the sender’s IP address will always be the same. To
enable Connection Filtering to work correctly, you need to add this smart host server’s
IP address, along with the IP addresses of all SMTP servers capable of routing e-mail, to
the InternalSmtpServers list via the Set-TransportConfig cmdlet. If the Hub server where
you enable anti-spam is the only SMTP server in your organization, you must add its own
IP address to the list.
IP Allow List
An IP Allow list is a static list of trusted IP addresses manually created and managed by the
Exchange server administrator. IP Allow list inspection is the first in the execution chain of
Connection Filtering. You can include trusted IP addresses in the IP Allow list, such as the
IP addresses of SMTP servers at your partner organizations. If a connection request comes
from an IP address on the IP Allow list, the server does not apply additional anti-spam
filtering and accepts the message.
To configure an IP Allow list and either add a single IP address or an IP range to the list,
you need to use the Add-IPAllowListEntry cmdlet.
Edge Transport and Messaging Security
IP Allow List Providers
IP Allow List Providers is a feature that allows you to take advantage of dynamic safe lists of IP
addresses maintained by a third-party providers. To use these lists you need to configure
an external provider that maintains a safe list of SMTP servers instead of defining it yourself.
In essence, configuring IP Allow List Providers is very similar to configuring IP Block List
Providers and both use the same technology to retrieve the verdict about the connecting
IP address from the providers.
Most of the messaging administrators I know do not consider IP Allow List
Providers for deployment and infrequently use IP Allow lists. This is due to the fact that all
messages submitted from the addresses on IP Allow lists are immediately extracted from
the anti-spam scanning and if a spam attack comes through one of the addresses on an IP
Allow list, it won’t be detected by the consecutive anti-spam layers and spam will penetrate
the Exchange organization. Although the adoption of the IP Allow List Providers feature is
not very significant, a carefully implemented static IP Allow list allows you to receive e-mail
from trusted parties fast, without the loss of content, increasing end users’ satisfaction.
IP Block List
Similar to the IP Allow list, the IP Block list feature examines connecting IP addresses against
the static local list of IPs manually maintained by the Exchange administrator. In many cases
administrators include on the list IP addresses of SMTP servers known to send spam or other
MTAs from which they do not want to receive e-mail. If the Connection Filtering agent finds
the IP address of the sending server on the local IP Block list, the server rejects the message
without allowing the connecting party to initiate SMTP mail transaction.
You can configure a single IP address or IP address ranges that are blocked, and you can
also define an expiration time on each entry so that you can block an IP address temporarily.
If you enable Sender Reputation filtering, it will add the IP addresses that exceed defined
Sender Reputation Level (SRL) to the IP Block list for the configured amount of time.
IP Block List Providers
IP Block List Providers, or real-time block lists (RBLs), contain a list of known IP addresses of
SMTP servers that are considered risky for sending spam. Because spammers use a variety
of techniques to send spam and fool the receiving servers into accepting it, identifying their
IP addresses and verifying them for “spamminess” is a very useful way to prevent spam from
entering Exchange organizations.
If enabled, the Agent will send a DNS query to a manually configured IP Block List Provider
and if the response from the provider indicates that the connecting IP is on the list, the
Connection Filtering agent will reject mail transaction after the RCPT TO: command.
The rejection logic has been designed to accommodate various exceptions or cases when
one or more recipients in the Exchange organization might need to receive all e-mail sent
Planning for Anti-Spam
from the block-listed IP because of various business needs. (For example, spam analysts might
need to investigate a newly unfolding spam attack or the Exchange administrator might set
up a honey pot account to collect mail for forensics.) Whatever the reason, you can configure
specific e-mail addresses as exceptions so that they will receive all messages, even if the
connecting IP is on the RBL.
There are multiple real-time IP Block List Providers who maintain and service RBLs. You
need to account for many factors when deciding which RBL provider to use. Some of the most
important factors are the ability of the provider to service requests for removal of mistakenly
or maliciously block-listed IP addresses, supportability channels, and responsiveness to
customer issues. Of course, you also need to account for the cost of using the provider’s
services. Most RBL providers do not charge fees if the number of DNS queries is relatively
low—for example it does not exceed 250,000 queries per day. However, if the number
of queries exceeds this threshold, the provider won’t service requests originating from
high-volume IP addresses and instead will ask you to obtain their list via a zone file transfer,
and the provider will charge a fee for that. Many RBL providers are available on the market,
including the following:
The list of common IP Block List Providers should be handled with care
because the results change over time. Please watch your Agent Log carefully to prevent the
blocking of messages without a reason. You should consider writing a PowerShell script
that is automatically executed every day to look for problems in the Agent Log as the size
of the log might increase very quickly.
A very useful cmdlet to determine whether your IP Block List Providers are working
correctly is the Test-IPBlockListProvider cmdlet. You can either test a single RBL or you can test
an IP address using all your configured RBLs, as shown in Figure 7-9.
FIGURE 7-9 Testing IP Block List Providers in EMS
Edge Transport and Messaging Security
Please be aware that the more RBLs you configure, the longer the verification process
will take. Thus it is recommended not to exceed two or three RBLs. One positive match is
sufficient to block the sender.
Another advantage of using Forefront Protection 2010 for Exchange Server is that it
relieves administrators of the work required to configure, maintain, and administer IP block
lists. The product comes with a feature called Forefront DNSBL, which is an aggregation
of multiple feeds from many RBL providers, including SpamHaus and internal Microsoft
feeds such as the block list from the Forefront Online Protection for Exchange team. The
aggregated feeds are combined into a single database and positioned on a Microsoft-owned
DNS infrastructure. The feature is administration- and maintenance-free, meaning the
Exchange administrator has nothing to configure or monitor/maintain.
Sender Filtering
The Sender filter compares the sender on the MAIL FROM: SMTP command to a list of senders
or sender domains that are prohibited from sending messages to the organization. After the
sender is filtered, there are two possible actions: reject the message or stamp the message
and deliver it. The blocked sender information is included as one of the criteria when content
filtering processes the message.
As a best practice you should select the Block Messages That Don’t Have Sender
Information option in Sender filtering properties. If a message does not contain a sender
address, it is extremely likely to be spam anyway.
Recipient Filtering
The Recipient filter compares the message recipients on the RCPT TO: SMTP command to
an administrator-defined Recipient Block list. If a match is found, the message is not accepted
for the recipient specified on the Recipient Block list but will be delivered to other recipients
who are not on the list. If multiple recipients are listed on the message and some are not
on the Recipient Block list, further processing is done on the message. The Recipient filter
also compares recipients on inbound messages to the local recipient directory to determine
whether the message is addressed to valid recipients. When a message is not addressed to
valid recipients, such a message can be safely rejected during SMTP transaction.
As a best practice you should select the Block Messages Sent To Recipients That
Don’t Exist In The Directory option in Recipient filtering properties. This will automatically
reject any message destined for e-mail addresses that do not exist in Active Directory.
This will be verified to all authoritative, configured Accepted Domains. For internal relay
domains this option will not be considered.
Planning for Anti-Spam
Enabling the Block Messages Sent To Recipients That Don’t Exist In The Directory option
might disclose your Active Directory recipient information to malicious users executing
a Directory Harvesting Attack (DHA) against your organization. To circumvent such attacks
Exchange server enables you to configure tarpit intervals (tarpits are delays between the
command coming from a remote computer and when Exchange server replies confirming
or rejecting valid recipients). This is a highly effective technique that renders DHAs against
Exchange organizations not feasible. The tarpit option is configurable and the default value
is 5 seconds (which means Exchange server will delay response to every invalid recipient
command for 5 seconds).
Sender ID Filtering
The Sender ID framework is an industry standard that allows companies to verify the IP
addresses for incoming messages to ensure that they come from authorized servers. The
Sender ID Framework provides highly effective protection against e-mail domain spoofing
and phishing schemes. However, Sender ID is not used by many large corporations.
To take an advantage of the Sender ID Framework, domain owners must register all the IP
addresses for all the SMTP servers that send e-mail from their SMTP domain with special DNS
records. When using Sender ID filtering, the recipient messaging server initiates a DNS lookup
to verify that the connecting IP is allowed to deliver messages on behalf of that domain. If the
domain information does not contain the connecting server’s IP address, the messages can be
filtered out. Figure 7-10 illustrates the Sender ID filtering process.
DNS Server
Hub Transport
FIGURE 7-10 How Sender ID filtering works
As displayed in the figure, Sender ID filtering follows these steps:
The message is received by the Exchange Edge Transport server.
The Edge Transport server checks the IP address of the sending SMTP server and
queries DNS for the Sender ID record. Sender ID records are in fact Sender Policy
Edge Transport and Messaging Security
Framework (SPF) compatible records and both SPF versions are supported in the
Sender ID Framework.
Depending on the result, the following actions are taken:
If the Sender ID record matches the sending SMTP server, the Edge Transport server
accepts the message into the Exchange organization.
If the Sender ID record does not match, the Edge Transport server will respond
in the configured way—meaning it either rejects, deletes, or forwards the
message with additional information added to its header indicating that it failed
If you’re interested in additional information about the Sender Policy Framework (SPF),
you can access it at
Sender ID and Sender Policy Framework (SPF) records
To take an advantage of the Sender ID Framework and protect their own name brand and
reputation, each e-mail sender must create a Sender ID or SPF record and add it to their
domain’s DNS records. The record is a single text (TXT) record in the DNS database that
identifies each domain’s e-mail servers. Sender ID records can use several formats, including
the SPF record format examples as listed in Table 7-5.
TABLE 7-5 SPF Record Configuration Examples
DESCRIPTION IN TXT "v=spf1 mx -all"
This record indicates that all
servers that have an MX record
for the domain are
allowed to send messages. IN TXT "v=spf1 ip4: –all"
This record indicates that only
the server with the IP address is allowed to send
messages for IN TXT "v=spf1 a -all"
This record indicates that any
host with an A record can
send mail. IN TXT "v=spf1 mx mx:berlin-et01
This record indicates that only the
listed servers are allowed to send
messages for mx:berlin-et02.emea –all"
Planning for Anti-Spam
Additionally, you should be aware of the different configuration options you have using
the all part of the SPF record in DNS. The options are listed in Table 7-6.
TABLE 7-6 SPF Record all Options
Only IPs in the text record can legitimately send mail on behalf of the
domain—otherwise the e-mail is a forgery. For example, “v=spf1 mx
–all” means only IPs of MX records can legitimately send on behalf of
the domain; all others are forgeries. You should always consider this
SPF record as the default.
However, “v=spf1 –all” means no IPs are associated with sending
domain and as such this domain is not involved in sending mail at all, so
all mail claimed to be from the domain is a forgery. This option maps to
hardfail status in Sender ID filter and the message will be deleted.
E-mail is likely a forgery but this is clear. Sender ID filter, encountering
such an option, will provide softfail status and the e-mail won’t get
deleted, but instead will get accepted into the Exchange organization.
Use this option with care as it maps to the PASS status in Sender ID filter.
By implementing this syntax you guarantee that your domain never
sends spam.
It’s ambiguous if the e-mail is a spoof or good. The option is used for
testing Sender ID functionality and maps to Neutral status and e-mail
will be accepted into the Exchange organization.
Microsoft provides the Sender ID Framework SPF Record Wizard to verify your
organization’s Sender ID and SPF records in DNS. It is available at
.com/mscorp/safety/content/technologies/senderid/wizard/. The wizard allows you to create
a Sender ID record that meets your organization’s exact needs.
Configuring Sender ID Filtering
Sender ID filtering is enabled by default with the option to stamp the header with Sender ID
verdict and continue message processing. Other possible options are Reject and Delete.
It is very important to understand that the filter will implement Reject or Delete actions
if and only if the Sender ID validation on the connecting IP failed. This means that the
connecting IP cannot legitimately send mail on behalf of the domain it claims to be from,
which is pretty much a spoofing attempt. In all other cases (for example, in the event of a
transient DNS error, or if Sender ID records are misconfigured, do not exist, or are temporarily
not available) the filter will not reject or delete message. It will stamp the verdict onto the
message and pass it on to the next filtering technology.
Sender ID is not a mandatory requirement in Internet SMTP messaging; however, it is the
technology that will help protect your company’s name brand and prevent spoofing attacks.
But the evidence is that many large companies don’t use Sender ID yet. For example, at the
Edge Transport and Messaging Security
time of this writing, neither HP nor GE nor Siemens publish Sender ID records in DNS; whereas
IBM, Microsoft, and Google do.
In many cases Sender ID is your best and only defense when Zero Day attacks unfold, so
it is recommended that you create and maintain Sender ID records and implement Sender ID
filtering in Reject mode. Sender ID, when correctly implemented, is very safe to use and helps
to improve your reputation as a responsible, legitimate sender.
To verify Sender ID, you can use the Test-SenderID cmdlet and enter a domain as well as
the Server IP address to see the result.
Content Filtering
The Content Filter agent uses SmartScreen technology to analyze the content of every
message and evaluate whether it is spam.
SmartScreen technology is the name for the underlying content filtering core technology
developed by Microsoft Research and used in multiple Microsoft products under various
names. In Exchange it is used under the name IMF (Intelligent Message Filter), whereas
Outlook uses SmartScreen in its Junk E-mail Filter. The same core engine is used in Hotmail as
well. The content filter uses the Microsoft Exchange Anti-Spam Update service to update its
After the message is received, the Content Filter agent evaluates the message’s content
for recognizable patterns and then assigns a rating based on the probability that the
message is spam. This rating is attached to the message as an SCL, which is a numerical value
between -1 and 9. Table 7-7 provides an overview of the SCL ratings and the spam confidence
level definition.
TABLE 7-7 SCL Ratings and Definitions
Messages are from a trusted source (internal, authenticated, or
Messages are categorized as not spam.
The likelihood of being spam is extremely low to low.
The likelihood of being spam is high to extremely high.
The Content Filter agent scans messages only on Edge Transport servers and Hub
Transport servers that have the anti-spam agents installed.
The SCL rating of the message is stored in the header of the message and can be
found by identifying the X-MS-Exchange-Organization-SCL value, as displayed in Figure 7-11.
Content filtering is enabled by default on Edge Transport servers (or Hub Transports
that have the anti-spam agents installed) and is configured to reject all messages with
an SCL rating equal or greater than seven.
Planning for Anti-Spam
FIGURE 7-11 Viewing the SCL rating of a message in Microsoft Outlook
Configuring the Content Filter
You can modify the default content filtering settings by using the Exchange Management
Console or the Exchange Management Shell:
Configure Custom Words You can specify a list of keywords or phrases to prevent
the blocking of any message containing those words. This feature is useful if your
organization must receive e-mail that contains words that the Content Filter agent
normally would block. You also can specify keywords or phrases that cause the Content
Filter agent to block a message containing those words.
Specify Exceptions You can configure exceptions to exclude any messages to
Specify Actions You can configure the SCL thresholds and threshold actions. You
recipients on the exceptions list from content filtering.
can configure the Content Filter agent to delete, reject, or quarantine messages with
an SCL rating equal or greater than the value you specify. You can also define the
quarantine mailbox.
When the Content Filter agent rejects a message, it uses the default response of
“550 5.7.1 Message rejected due to content restrictions”. You can customize this message
using the Set-ContentFilterConfig cmdlet in the Exchange Management Shell.
Configure SCL Junk E-Mail Folder Threshold
Besides configuring the Content Filter to reject, quarantine, or delete messages on
the incoming stream, you can also configure SCL threshold levels to move mail items
automatically to the Junk folder of the mailbox. You can configure this either on a mailbox
level or an organizational level.
Edge Transport and Messaging Security
The SCL Junk E-mail threshold configuration means that Exchange automatically
moves the messages to the Junk folder. If the messaging client of your users does not
allow the Junk folder to be accessed, users will never be aware of the junk mail. This is not
a problem if your users are using Outlook or OWA. For POP3 clients, if you turn on the SCL
thresholds, recipients won’t be able to see mail sent to the Junk E-mail folder (as the POP3
protocol doesn’t know the Junk E-mail folder), and IMAP4 clients should include the Junk
E-mail folder in the list of subscribed folders for their client.
To configure specific junk mail parameters on a single mailbox, you need to use the
Set-Mailbox cmdlet. This cmdlet includes various parameters that allow you to configure SCL
thresholds and their actions. Table 7-8 provides an overview of which SCL thresholds can be
TABLE 7-8 Set-Mailbox Cmdlet Anti-Spam Parameter Overview
If set to $true, no anti-spam agent will scan
a message from or to this mailbox.
If this is configured, any sender that addresses
this mailbox must be authenticated.
Defines the SCL threshold for the mailbox
that deletes any messages rated equal or
above the threshold.
SCLDeleteThreshold <SCL#>
Defines the SCL threshold for the mailbox
that moves any message rated equal or
above the threshold to the Junk folder.
When SCLJunkEnabled is set to $True and
SCLJunkThreshold is a value such as 5, the
setting ignores the organizational setting.
Defines the SCL threshold for the mailbox
that moves any message rated equal or above
the threshold to the quarantine mailbox.
Defines the SCL threshold for the mailbox
that rejects any messages rated equal or
above the threshold.
You can also define an SCL threshold level for every mailbox in your Exchange organization
by using the following cmdlet:
Set-OrganizationConfig –SCLJunkThreshold <SCL #>
Planning for Anti-Spam
If the SCL rating for a specific message exceeds the SCL Junk E-mail folder threshold, the
Mailbox server moves the message to the user’s Junk E-mail folder. The default value is 4.
Create a Transport Rule to Process SCLs
Andreas Bode
Messaging Consultant, Siemens AG, Germany
ne of my customers wanted to identify SPAM by adding the word SPAM: to
the message subject as a prefix. Using Transport rules it is very easy to add the
word SPAM: as the prefix for the SCL rating I defined. However, I recognized that
the rule did not catch the SCL rating at all.
After some research I found out that the problem was caused by the priority at
which the Transport agents are processed. By default, Edge Rule Agent has a priority
of 3 and Content Filter Agent of 4. Practically, this means that the rule is executed
before the Content Filter agent sets an SCL rating on the message.
To solve this problem I executed the following cmdlet to move the Content Filter
Agent in priority before the Edge Rule Agent: Set-TransportAgent “Content Filter
Agent” –Priority 3 cmdlet. After a Transport service restart, my Transport rule
marked all messages that exceeded the SCL threshold I defined accordingly.
Safe List and Block List Aggregation
In Exchange Server 2010, the Content Filter agent on the Edge Transport server uses the
Microsoft Outlook Safe Senders lists, Safe Recipients lists, and trusted contacts to optimize
spam filtering. Safelist aggregation is a set of anti-spam functionality that Outlook and
Exchange Server 2010 share. This anti-spam functionality collects data from the anti-spam
safe lists that Microsoft Outlook or OWA users configure, and makes this data available to the
anti-spam agents on the Edge Transport server.
Unlike in Exchange 2007, in Exchange 2010 safelist aggregation is enabled by default. The
Mailbox assistant does the safelist aggregation automatically. Another difference between
Exchange 2007 and Exchange 2010 servers is Block list aggregation. In Exchange 2007
the Block list logic was triggered at the client end but in Exchange 2010 server the logic is
transferred to the Sender filter and executed much earlier in the anti-spam processing. So
in addition to existing Safe Sender/Recipient lists aggregation Exchange 2010 server also
aggregates Block list entries, making them available to Sender filtering.
The safelist collection is stored in a hidden item in the root folder of the user’s mailbox.
A user can have up to 1,024 unique entries in a safelist collection. Exchange 2010 and the Junk
Edge Transport and Messaging Security
E-mail Options mailbox assistant then replicate the changes from the mailbox to the user’s
Active Directory account (namely to the msExchSafeSenderHash, msExchSafeRecipientHash,
and msExchBlockedSendersHash attributes).
EdgeSync then synchronizes the safelist collections to the Edge Transport servers where
the aggregated data is used by the Content Filtering agent.
Unlike Exchange 2007, you do not need to run Update-Safelist cmdlet to gather and
prepare safelist data from user mailboxes anymore. However, you can use the Update-Safelist
cmdlet to manually update the safelist in Active Directory.
You can find more details at
Sender Reputation Filtering
The Exchange Server 2010 Sender Reputation feature makes message-filtering decisions
based on information about recent e-mail messages received from specific senders. The
Sender Reputation agent analyzes various properties about the sender and the e-mail
message, to create a Sender Reputation Level (SRL). This SRL is a number between 0 and 9,
where a value of 0 indicates less than a 1 percent chance that the sender is sending spam, and
a value of 9 indicates more than a 99 percent chance of it. If a sender appears to be the spam
source, the Sender Reputation agent automatically adds the IP address for the SMTP server
that is sending the message to the IP Block list.
How Sender Reputation Filtering Works
When the Transport server receives the first message from a specific sender, the SMTP
sender is assigned an SRL of 0. As more messages arrive from the same source, the Sender
Reputation agent evaluates the messages and begins to adjust the sender’s rating. The Sender
Reputation agent uses the following criteria to evaluate each sender:
Sender open proxy test An open proxy is a proxy server that accepts connection
requests from any SMTP server, and then forwards messages as though they originated
from the local host. This also is known as an open relay server. When the Sender
Reputation agent calculates an SRL, it does so by formatting an SMTP request in an
attempt to connect back to the Edge Transport server from the open proxy. If an SMTP
request is received from the proxy, the Sender Reputation agent verifies that the proxy
is an open proxy and updates that sender’s open proxy test statistic.
HELO/EHLO analysis The HELO and EHLO SMTP commands are intended to
provide the receiving server with the domain name, such as, or the
IP address of the sending SMTP server. Spammers frequently modify the HELO/
EHLO statement to use an IP address that does not match the IP address from
which the connection originated, or to use a domain name that is different from the
actual originating domain name. If the same sender uses multiple domain names
or IP addresses in the HELO or EHLO commands, there is an increased chance that
the sender is a spammer.
Planning for Anti-Spam
Reverse DNS lookup The Sender Reputation agent also verifies that the originating
IP address from which the sender transmitted the message matches the registered
domain name that the sender submits in the HELO or EHLO SMTP command. The
Sender Reputation agent performs a reverse DNS query by submitting the originating
IP address to DNS. If the domain names do not match, the sender is more likely to be
a spammer, and the overall SRL rating for the sender is adjusted upward.
SCL ratings analysis on a particular sender’s messages When the Content
Filter agent processes a message, it assigns an SCL rating to the message. This rating is
attached to the message as an SCL. The Sender Reputation agent analyzes data about
each sender’s SCL ratings, and uses it to calculate SRL ratings.
The Sender Reputation agent calculates the SRL for each unique sender over a specific
time. When the SRL rating exceeds the configured limit, the IP address for the sending SMTP
server is added to the IP Block list for a specific amount of time.
Sender Reputation Configuration
You can configure the Sender Reputation settings on the Edge Transport server. By using the
Exchange Management Console, you can configure the Sender Confidence (enable or disable
Sender open proxy test), the Sender Reputation block threshold, and the timeout period for
how long a sender will remain on the IP Block list. Figure 7-12 shows the default settings of
Sender Reputation filtering.
FIGURE 7-12 Sender Reputation default settings
If you want to configure advanced settings, you need to use the Set-SenderReputation
cmdlet, which allows you to fine-tune this feature.
Edge Transport and Messaging Security
Attachment Filtering
Attachment filtering allows you to choose the attachment names, file extensions, or file MIME
content types your users can receive. This is necessary to protect your users from malicious
messages. One of the most famous viruses in messaging history, the Melissa virus, was spread
using a malicious attachment. Obvious dangerous attachments such as scripts or executables
are now removed after causing a complete mail disruption for large organizations years
ago. You may remember the “I love you” virus that sent messages to all contacts of the local
mailbox. That’s just one good reason to consider attachment filtering!
Attachment filtering in Exchange 2010 can be based on the following filtering criteria:
Filename or filename extension
File MIME content type
You can use the Get-AttachmentFilterEntry cmdlet to display the currently configured
attachment filters, as shown in Figure 7-13.
FIGURE 7-13 Default attachment filter entries
When a filtering criterion is met, the following actions can be performed on the
Strip attachment but deliver message
Block message and attachment This blocks the message from entering the
system but will inform the sender of the message that the message contained
an unacceptable attachment.
Silently delete message and attachment This will delete the message before
entering the system without sending any notification to the sender or recipient.
Attachment filtering is only available on Edge Transport servers, not on Hub Transport
servers, even if you installed the anti-spam agents.
Planning for Anti-Spam
The Attachment Filter agent included with Exchange 2010 detects file types even
if they have been renamed. Attachment filtering also ensures that compressed files (.zip
or .lzh files) don’t contain blocked attachments by performing a filename extension match
against the files in the compressed files.
Anti-Spam Reporting
Exchange 2010 comes with a couple of scripts to create anti-spam activity reports that are
available in the <Exchange_Install_Path>\Scripts folder. These scripts can run on Edge and
Hub Transport servers. Table 7-9 provides an overview of available scripts and their usage.
TABLE 7-9 Anti-Spam Reporting Scripts
Creates a top-ten list of sources (such as
agents) that are responsible for either
rejecting connections and commands
or for rejecting, deleting, or quarantining
a message.
Retrieves all entries for the Content Filter
and groups them by SCL values.
Lists the top sender domains that were
blocked by anti-spam agents.
Lists the top sender IPs that were blocked
by anti-spam agents.
Lists the top sender IPs that were blocked
by anti-spam agents.
Lists the top reasons for rejection by Block
List Providers.
Lists the top recipients that were rejected
by anti-spam agents.
All of these example Windows PowerShell scripts use the transport agent logs and analyze
them. All anti-spam agents log information about connections and messages acted on,
plus some contextual information such as the name of the RBL or the SCL of the e-mail.
The transport agent log files are located at <Exchange_Install_Path>\TransportRoles\Logs\
Edge Transport and Messaging Security
Custom Agent Log Analyzer
Jon Webster
Systems Engineer, Elephant Outlook, U.S. Southeast
xchange 2010 and Forefront Protection 2010 for Exchange Server (FPE) both
store their transaction and agent logs in CSV files.
The built-in Get-AgentLog cmdlet first loads the entire set of CSV file(s) into
Windows PowerShell objects; then they can be filtered further. I have achieved
a significant performance boost using my Select-CSVString script (available at by filtering the lines as text first, and then converting
just those results to Windows PowerShell objects.
Let’s assume the following: A user on our system has opened a support ticket
saying she was supposed to get an e-mail from someone at, and it
never arrived. Rather than getting the sender to locate the bounce message, we can
search the agent logs and see if something from that domain was rejected within
the last few days.
To look for this rejection using the built-in tool, I would use something like this:
Get-AgentLog |?{ ($_.p1fromaddress -match "" -or
$_.p2fromaddresses -match "") -and $_.action -eq
Get-AgentLog loads several gigs of agent logs, filters through potentially hundreds
of thousands of results, and finishes several minutes later.
To look for the same line with Select-CSVString, I would use something like this:
Select-CSVString -pattern "*Reject"
Select-CSVString searches several gigs of agent logs for the above regular
expression, converts just those results into Windows PowerShell objects, and return
similar results in under 30 seconds. I say similar, because Exchange and Forefront
can actually use multiple lines for a single message (multiple recipients) that
Select-CSVString doesn’t handle—it could, but there just hasn’t been much interest.
Couple that with another script to run Select-CSVString against all edge servers
and Hub Transport servers that run the anti-spam agents using WinRM, and you
can imagine the time it saves your support staff.
Planning for Anti-Spam
Antivirus Considerations
Besides planning for anti-spam, you need also to consider protecting your Exchange
organization from viruses or other dangerous software applications.
Exchange Server 2010 Antivirus Protection
E-mail is one of the most common ways to spread viruses from one organization to another.
The security community even refers to email as a vector used to spread viruses. One of the
primary tasks in protecting your Exchange Server organization is to ensure that all messages
containing viruses are stopped at the messaging environment’s perimeter.
Although Exchange Server 2010 already provides some basic antivirus features, it
is important to implement a separate antivirus product based on VSAPI that supports
Exchange 2010.
Exchange Server 2010 includes the following virus protection features:
VSAPI Support of the Virus Scanning application programming interface
(VSAPI) In Exchange Server 2010, Microsoft maintains support for the same VSAPI
used in Exchange Server 2003 and Exchange Server 2007. VSAPI does not reduce any
viruses unless you install a product that uses VSAPI to scan your messages and remove
viruses when messages have been infected.
Transport agents that filter and scan messages Exchange Server 2010 includes
the concept of transport agents—such as the attachment filtering agent—to remove
spam and viruses from the messaging stream. By enabling attachment filtering on
the Edge Transport or Hub Transport servers, you can reduce the spread of malware
attachments before they enter the organization. Additionally, third-party vendors can
create transport agents that specifically scan for viruses. Because all messages must
pass through a Hub Transport server, this is an efficient and effective means to scan all
messages in transit.
Antivirus stamping Antivirus stamping reduces how often a message is scanned
as it proceeds through an organization. It does this by stamping scanned messages
with the version of the antivirus software that performed the scan and the scan results.
This antivirus stamp travels with the message as it is routed through the organization,
and determines whether additional virus scanning must be performed on a message.
Considerations for Deploying an Antivirus Solution
Many antivirus solutions are available on the market. Exchange 2010 requires a solution that
supports VSAPI, such as Symantec Mail Security for Microsoft Exchange, Trend Micro ScanMail
Suite for Microsoft Exchange, or the Microsoft’s Forefront Protection 2010 for Exchange
Server. Just make sure VSAPI and Exchange 2010 are supported when you evaluate the best
antivirus solution for your company.
Edge Transport and Messaging Security
Although implementing an antivirus solution in Exchange Server is straightforward, you
should keep some factors in mind when choosing and configuring an antivirus solution.
Implementing Multiple Antivirus Layers
To provide enhanced security against viruses, you should implement multiple layers of
antivirus protection. A virus can enter your organization from the Internet through an e-mail
or from a non-protected client within your company. Thus, it is a best practice to implement
several layers of antivirus protection such as a firewall, a bastion server such as an Edge
Transport server, and at the client-computer level.
Maintaining Regular Antivirus Updates
Installing the antivirus product does not automatically mean that your organization is fully
protected. Regular antivirus pattern updates are critical to a well-implemented antivirus
solution. You should also monitor that your antivirus patterns are updated frequently.
If you have a Microsoft System Center Operations Manager 2007 R2 environment in
your organization, you can make sure that pattern updates of your antivirus solution are
monitored with a respective SCOM management pack if available. This will ensure that you
are notified when a pattern update does not occur in a timely manner.
Using Forefront Protection 2010 for Exchange Server
Forefront Protection 2010 for Exchange Server is a separate message-hygiene software
package that you can integrate with Exchange Server 2010 to provide antimalware
and anti-spam protection for the Exchange environment.
Benefits of Forefront Protection
Forefront Protection 2010 for Exchange Server (FPE) was specifically developed for Exchange
Server and thus provides rich antivirus and anti-spam functionality for medium to large
enterprises. FPE supports Exchange 2007 SP1 and later versions.
Forefront Protection 2010 for Exchange Server extends Exchange Server 2010 with the
following advanced protection features:
Simple configuration/maintenance-free setup
Auto-configured anti-spam agents with smart defaults
Unified management of FPE, Exchange, and Forefront Online Protection for Exchange
Premium multiple engine antimalware protection
Leading anti-spam content filter engine with spam catch rate above 99 percent
An overview of the ways FPE provides benefits when implementing it together with
Exchange 2010 can be found in Table 7-10.
Antivirus Considerations
TABLE 7-10 Forefront Protection 2010 for Exchange Server Overview
Malware scan with multiple engines
You can automatically scan messages using
multiple malware pattern engines, not just
a single one. Single antimalware engine creates
a single failure point in the entire deployment;
with Forefront you can use five engines
scanning the messaging stream simultaneously
and thus remove this deficiency.
New Microsoft antispyware engine
Scans messages for spyware.
Intelligent Engine Management
Automatically tracks the most efficient and
performing engines and forces them to execute
on the messaging stream first. Enables these
engines as a part of dynamically chosen subset
of engines.
Full support for VSAPI
Forefront Protection 2010 for Exchange Server
fully supports the Exchange VSAPI.
Forefront DNSBL service
Provides aggregated sender reputation information
supplied by multiple external and internal vendors
about IP addresses that are known to send spam.
This is an IP Block list offered exclusively to
Exchange Server.
Premium spam protection
Includes the new Cloudmark-based Content
Filter engine.
Automatic content filter updates
Automatic updates for the content filter directly
from the vendor’s update site. Microupdates are
available every 30 to 45 seconds without any
manual interaction.
Backscatter protection
Forefront Protection 2010 includes new
backscatter filter to prevent bogus NDRs from
entering Exchange organization.
Integration with Forefront Online
Protection via Hybrid Model
Allows you to implement both on-premises
and online protection from a single connection
point (via Forefront UI) and apply a single policy
to both online and on-premises protection. This
also allows for lowering TCO of messaging hygiene
and malware protection.
Unified protection management
New administrative and monitoring model
via Windows PowerShell support with new
dashboard implementation. Consolidated support
for all protection features and technologies
including basic Exchange anti-spam filters.
Edge Transport and Messaging Security
Hyper-V support
Is fully supported in a Hyper-V virtual
True Type File Filtering
Enables Real File Type inspection (not just
extension) and actionable scanning of nested
files/within .zip attachments.
Global Exception Lists
Single access point to sender and recipient
exception lists to enforce allow and block
actions from a single place.
Streamlined SCL ratings
Less ambiguous SCL ratings to simplify spam
categorization and decrease the false positive
rate. The vast majority of mail is correctly
classified as either spam or good, legitimate mail.
Sender/sender domain, File,
Keywords, and Subject Line filters
Allow scanning of incoming, outgoing, and
internal messaging streams.
Forefront Protection 2010 Deployment Options
When you implement Forefront Protection 2010 for Exchange Server, you must consider the
various deployment options.
First, you need to determine the servers on which you plan to install Forefront
Protection 2010 by considering the following criteria:
As a baseline, you should at least deploy Forefront Protection 2010 for Exchange
Server on all Edge and Hub Transport servers.
For full protection, you should deploy Forefront Protection 2010 for Exchange
Server on all Edge Transport, Hub Transport, and Mailbox servers.
You do not need to install Forefront Protection 2010 on the Client Access Server
role because Forefront is only needed on the Mailbox, Edge, or Hub Transport server roles.
By default, FPE scans each e-mail only once and then stamps it with a special AV Stamp
so that other servers do not scan that message again. However, if necessary, you can enable
rescanning of messages already scanned by FPE. Best practices also call for enabling FPE
on Mailbox servers, but you need to rationalize the number of engines to run. Scanning
with a dynamically allocated subset of engines looks like very attractive option and it is
recommended that you have at least one engine enabled for scanning Mailbox servers.
Periodic rescanning of databases provides additional assurance that there are no missed or
hidden threats in the accepted messages and allows for proactive protection against various
threats. You should also consider enabling periodic on-demand scanning of mailboxes to
remove offensive or malicious content delivered in the past.
Antivirus Considerations
As a best practice, you should enable at least three scan engines and select the Scan With
A Dynamic-Chosen Subset of Engines option, which provides optimal protection without
significantly sacrificing server performance or messaging throughput.
Forefront Protection 2010 for Exchange Server, compared to Forefront Security for
Exchange 2007, improves messaging throughput from 25 to 40 messages per second with all
five engines running.
Planning for Messaging Security
Secure messaging in Exchange 2010 can be separated into three levels: network-based,
session (or SMTP)–based, and client-based. It is important to understand at what level you
want to implement protection. For example, if you implement network- or session-based
security, messages are still not encrypted in a user’s mailbox. Only client-based security does
this. Alternatively you can also consider implementing security at every level, which definitely
never can be reached.
Implementing Network-Based Security
Network-based security basically protects the communication on the network layer using
protocols such as IPsec or VPN.
IPsec provides a set of extensions to the basic IP protocol and is used to encrypt
server-to-server communication. It can be used to tunnel traffic or peer-to-peer to secure
all IP communications natively. Because IPsec operates on the transport layer, applications
such as Exchange 2010 don’t need to be aware of IPsec. You use IPsec normally to secure
server-to-server or client-to-server communication. You do not need another encryption
method when using IPsec.
Virtual private network (VPN) also operates on the transport layer, and very often uses
IPsec as the underlying protocol. VPN is used for site-to-site or client-to-site connections.
Both operate on the transport layer, which can be an advantage over application-layer
protocols such as Secure MIME (S/MIME), which does not require the application on both
ends to know about the protocol.
Because Exchange 2010 by default encrypts its network traffic using TLS and self-signed
certificates (if you do not by default roll out server certificates), the requirements for using
network-based security for Exchange 2010 are not that important anymore.
Of course, Exchange 2010 also takes advantage of whether you have already implemented
network-based secure communication. You don’t need to do anything to make Exchange
2010 work; however, to optimize performance, you should consider configuring your
connectors accordingly when you have network-based security in place.
Let’s assume IPsec is mandatory for all Exchange servers in your organization. You now
only need to configure the Receive connectors of your Hub Transport servers and enable
Externally Secured on the Authentication tab, as shown in Figure 7-14. Externally Secured
Edge Transport and Messaging Security
means that the connection is considered secured by a security mechanism that is external to
Exchange 2010.
FIGURE 7-14 Configuring network-based security on a connector
Normally you don’t need any other authentication method, but you’re able to add only
Transport Layer Security (TLS) on top of your network security. However, this will decrease the
performance of message transfers because the communication gets encrypted several times.
Other options, such as Exchange Server authentication, do not work with Externally Secured.
Additionally, you need to configure Exchange Servers on the Permission Groups tab of the
Receive connector because this group is used to permit a connection to the server.
Implementing network-based security is a work-intensive solution. Unless you have
already implemented IPsec or other network-based protocols, you may want to consider
other options for Exchange 2010.
Planning for Session-Based Security
The TLS protocol is the default protocol used in an Exchange 2010 organization to encrypt
server-to-server communication. TLS uses either an available local computer certificate or
self-signed certificates that are created during Exchange 2010 setup. This means self-signed
certificates provide Exchange 2010 administrators with an easy way to have OWA or other
services automatically secured. Self-signed certificates are also used to automatically encrypt
Planning for Messaging Security
messages between Hub Transport and Edge Transport servers to encrypt traffic. They also are
used to encrypt traffic between two Edge Transport servers located in different organizations.
If you’re planning to implement Exchange 2010 Domain Security to provide secured
message paths between Exchange 2010 Edge Transport servers over the Internet, you
need real certificates. Self-signed certificates do need extra work when you want to
implement Domain Security such as exchanging, installing, and trusting the root Certificate
Authority (CA) between both companies.
Domain Security uses TLS with mutual authentication (mutual TLS) to provide
session-based authentication and encryption. Standard TLS is used to provide confidentiality
by encrypting but not authenticating the communication partners. This is typical of Secure
Sockets Layer (SSL), which is the HTTP implementation of TLS.
Certificates and TLS
The section “Planning Certificates” in Chapter 3 already included the basics about digital
certificates and Exchange Server 2010. It also mentioned the requirements for Hub and Edge
Transport servers when using TLS.
Because Hub Transport servers can also use self-signed certificates for their internal
communication, what you need to consider here are your Internet-facing Transport servers.
On these servers it is recommended that you use an official certificate purchased from
a third-party certificate authority (CA) that is well trusted.
The most important requirement on a certificate is to include the following names
as SANs:
The top-level domain for your Exchange organization that your users use in their
official e-mail addresses, such as
All FQDNs of the Edge Transport servers
Remember that you cannot modify the SANs of a certificate afterward; if
you miss a name in the certificate request, you have to create a new one.
Any certificate that you want to use for TLS requires the following:
It must be a certificate that was either issued by a trusted party (by importing their
root certificate) or by a third-party CA.
It needs to be installed on the computer’s certificate store.
The certificate must be valid.
It must be enabled on the Edge Transport server(s) for SMTP service.
On the Edge Transport server you cannot configure certificates in EMC; you have to
use the Exchange Management Shell. The cmdlet to enable services for a certificate is
Edge Transport and Messaging Security
Enable-ExchangeCertificate. The cmdlet to verify that the certificate is enabled you can use is
Get-ExchangeCertificate |fl, as shown in Figure 7-15.
FIGURE 7-15 Enabling a certificate for SMTP service
To verify that your Edge Transport server is ready to serve mutual TLS requests, you
should use the command TELNET <servername> SMTP and verify that when you enter the
SMTP command EHLO you see STARTTLS listed. If it is not listed, check your Event Viewer’s
application log to find out what is wrong with your certificate.
Planning for Domain Security
Domain Security in Exchange 2010 is used as a relatively low-cost alternative to S/MIME
or other message-encryption solutions. It uses mutual TLS, where each server verifies the
identity of the other server by validating the certificate that is provided by the other server. It
is an easy way for administrators to manage secured message paths between domains over
the Internet.
TLS with mutual authentication differs from TLS in its usual implementation. Typically,
when you implement TLS, the client verifies a secure connection to the intended server by
validating the server’s certificate, which it receives during TLS negotiation. With mutual TLS,
each server verifies the connection with the other server by validating a certificate that the
other server provides.
Domain Security is manually enabled for every domain by an Exchange organization
administrator, so you must coordinate with the communication partner to make it work.
It cannot be enabled only on one side, but must be configured in both the sending and
receiving organizations.
Typically, Domain Security is enabled only on an Edge Transport server because the
server needs to reside in the perimeter network or directly on the Internet to communicate
with other domains. However, you also can enable Domain Security on a Hub Transport
server if needed.
Planning for Messaging Security
The high-level steps to implement Domain Security are as follows:
Request and install a SAN certificate on the Edge Transport server(s) where you want
to enable mutual TLS.
Test that TLS is working on both your side and the partner’s side.
Configure outbound and inbound Domain Security.
Test mailflow.
Don’t forget to check your partner’s domain to verify that it supports
mutual TLS before configuring outbound and inbound Domain Security. If a mutual TLS
connection cannot be made, all message traffic will stop.
To configure Domain Security, you need to connect to a Hub Transport server (because
it is synchronized to the Edge server using EdgeSync) and run the following commands in
the EMS:
To enforce Domain Security on an outbound connection, use the following cmdlet:
Set-TransportConfig -TLSSendDomainSecureList <DomainList>
To enforce domain security on an inbound connection, run this cmdlet:
Set-TransportConfig -TLSReceiveDomainSecureList <DomainList>
You need to configure this on a per-domain level. The domain list is not additive—new
domains are not automatically added, but replaced. You have to separate the domains using
a comma. For example, you can use the following cmdlet to configure outbound domain
security for the domains and
Set-TransportConfig -TLSSendDomainSecureList,
Because you are performing this configuration on your Hub Transport servers, it
takes a synchronization cycle before your Edge servers will recognize it. To speed up this
process, you can use the Start-EdgeSynchronization cmdlet.
Your last task is to make sure that the Send connectors and Receive connectors are
enabled for Domain Security (Mutual Auth TLS). This is the default configuration, which is
enabled if you do not change anything. The Send connector must be configured on the
Hub Transport server; the Receive connector must be configured directly on the Edge
Transport server.
When you’ve configured everything correctly, messages from any domain that are on the
Domain Secure List should display the Domain Secured icon in Outlook 2007 or later, as seen
Edge Transport and Messaging Security
in Figure 7-16. If the icon is not displayed, Domain Security might not work correctly and you
should do the following to find the issue:
Check the Event Viewer’s application log.
Check the Queue Viewer in the Exchange Management Console’s toolbox.
Enable Protocol logging on the Internet-facing connectors and take a look into the
SMTP log conversation.
FIGURE 7-16 Domain Secured icon in Outlook 2007
Implementing Client-Based Security
When you consider client-based security, usually you must also consider Secure Multipurpose
Internet Mail Extensions or S/MIME. S/MIME is a standard for public-key encryption and
signatures of e-mail messages. Encryption is used to protect the content of a message so that
only the intended recipients can read it. Signing a message means that the recipient can
verify whether the message has been changed on the way from the sender to the recipient.
S/MIME is a client-based encryption and signing protocol that provides end-to-end
security from the sending mailbox to the receiving mailbox. Unlike other encryption protocols
that are session-based on the transport layer (such as TLS), the message also remains
encrypted and signed within the mailbox. Even administrators cannot decrypt it if their digital
certificate does not allow them to do so. Implementing S/MIME offers the following abilities:
Use digital signatures as a way to prove to your communication partners that the
content was not altered.
Authenticate messages (especially for crucial functions such as when your boss
approves your travel requests).
Encrypt messages to prevent accidental disclosure of the content.
To support S/MIME in your Exchange organization, you must either have a public key
infrastructure (PKI) available or your clients need to configure their certificates locally on each
client (both their own and the public certificates from the person with whom they want to
communicate securely).
Planning for Messaging Security
If you use Windows PKI, all public certificates of your users are stored in your Active
Directory. This allows your users to securely communicate with each other internally.
However, if your users often communicate with external partners, you can also make the
partner’s certificate available in Active Directory. You do this by creating a contact and then
publishing the contact’s public certificate to it. You can find more information in the “Publish
certificates for external contacts in Active Directory” available at
By default, Exchange Server 2010 fully supports S/MIME for message encryption
and signatures. Unlike in previous versions where you had to configure every mailbox
database, you do not need to configure any server-side setting to support S/MIME.
Because S/MIME provides end-to-end security, it is important that the e-mail application
you use to read and write S/MIME messages meets the following two requirements:
It must support S/MIME encryption and signatures.
The digital signature must be configured in the e-mail application.
Outlook Web App running on a Windows system supports S/MIME. If you run OWA on
a LINUX system, you do not have the S/MIME feature available and thus you cannot encrypt
or decrypt S/MIME messages.
Additional Resources
Understanding Header Firewall:
Understanding Anti-Spam Stamps:
Sender Policy Framework – Project Overview:
Sender ID Framework SPF Record Wizard:
Understanding Safelist Aggregation:
Publish certificates for external contacts in Active Directory: http://
Edge Transport and Messaging Security
Automated Message
Processing, Compliance,
and Archiving
Messaging Compliance Overview 346
Designing and Implementing Messaging Records Management 348
Designing and Implementing Transport Rules
Designing and Implementing Message Journaling
Designing and Implementing Personal Archives
Multi-Mailbox Search 373
Designing and Implementing AD RMS Integration
Designing and Implementing Message Classifications
he messaging landscape has changed considerably over the last 10 years with the
introduction of a great deal of government and regulatory body legislation and
regulation. This has added to the already existing possibility of legal discoveries resulting
from litigation or other legal action, with their attendant cost in time and resources.
All of these factors have caused compliance requirements to become a major concern
for messaging professionals in organizations of all sizes. Historically, Exchange did not
offer features to manage messaging compliance and these requirements were met
with third-party solutions, sometimes using the journaling capabilities in Exchange
Server 2003 and earlier versions, or providing similar capability through their own
solutions. Exchange Server 2007 introduced capabilities and features that have allowed
organizations to meet some of these compliance requirements in a cost-effective
manner without having to integrate third-party solutions, and Exchange Server 2010 has
expanded on these capabilities to further build upon your ability to meet these needs
out of the box.
Messaging Compliance Overview
The e-mail compliance capabilities introduced in Exchange Server 2007 and built on in
Exchange Server 2010 are focused on regulatory compliance and legal discovery. In this
context, legal discovery refers to the requirement to produce all relevant e-mail during
litigation, usually as the result of a subpoena. Compliance can generally be divided into three
Regulatory Governmental regulations are normally the driving force behind
regulatory compliance. Regulatory compliance has been a predominant concern to
the financial services and healthcare sectors, but is also a matter of importance to
virtually all public and private sectors. Public sector organizations typically also are
expected to comply to access to information requests from citizens. Some examples
of regulations affecting the private sector in the United States include Sarbanes-Oxley,
SEC Rule 17A-4, Gramm-Leach-Bliley, and the Health Insurance Portability and
Accountability Act (HIPAA); concerns for the public sector include the Freedom of
Information Act and the Federal Information Security Management Act (FISMA).
Finally, protection of privacy information is a primary concern for all organizations,
whether in the public or private sectors.
Legal (court-ordered) Litigation is commonly the driving force behind legal
Internal Internal compliance in most cases boils down to risk mitigation for the
organization. These risks can encompass concerns such as privacy breaches, financial
loss, human resources concerns such as harassment/discrimination, corporate liability
(criminal or civil), intellectual assets disclosure, and breach of client/attorney privilege.
Some sources estimate that as much as 90 percent of compliance costs for an organization
are staff-related, and that the overall cost of compliance runs into the billions for sectors
such as financials and securities. The features provided in Exchange Server 2010 can enable
organizations to meet their compliance requirements with a much lower price tag in cost and
effort as well as reduced complexity.
As part of their design goals to satisfy customer needs for messaging compliance within
Exchange, Microsoft determined that although regulations vary widely across different
jurisdictions, a complete e-mail compliance solution can primarily be defined by the following
Message Retention Defined not only as the ability to retain e-mail automatically
for pre-determined time periods, but also the functionality to locate and retrieve
those e-mails when necessary. If you’ve retained the records, but can’t find them
when needed, retention alone has done no good. Legal discoveries (subpoenas) in
the private sector as well as access to information requests in the public sector are the
Automated Message Processing, Compliance, and Archiving
primary drivers behind message retention. In Exchange Server 2010, these capabilities
are provided by journaling, retention policies, retention policy tags, personal archives,
and multi-mailbox search.
Controlled Access Aside from retaining records as required, another capability
required by a compliance solution is the ability to protect privacy information and
prevent unauthorized access to data, both in transit and at rest. Exchange Server 2010
provides this capability through integration with Active Directory Rights Management
Services (AD RMS), transport rules, and Transport Layer Security (TLS) for SMTP.
Information and Process Integrity This capability encompasses message
classification and processing messages based on their classification. It may also include
ethical walls to block communication between specified departments or individuals
of the organization to help preclude conflicts of interest. An example of an ethical
wall is a financial institution that provides both brokerage and market research
services; these groups are typically mandated by regulations to not communicate
with each other in any way. Message classifications are an integrated component in
Exchange Server 2010, whereas ethical walls can be implemented using transport
rules in Exchange Server 2010. Both message classifications and transport rules were
introduced in Exchange Server 2007.
Successfully Implementing Messaging Compliance Technologies
Ed Banti
Program Manager, Microsoft Corporation, Redmond, WA
ny technology implementation intended to impose certain behavior on end
users or for policy enforcement (and the technologies discussed in this chapter
certainly fall into these categories) can encounter challenges along the way that
prevent the implementation from being a success. Primary among these challenges
is the lack of a clearly defined and enforced corporate e-mail policy; this policy
is the cornerstone of a successful compliance implementation. A large portion of
messaging compliance is fundamentally policy enforcement, so without a defined
policy in place you’re like a dog chasing its tail; you may be getting good exercise,
but you’re not accomplishing anything.
A corporate e-mail policy is not a technical document—it’s a business policy created
by your compliance or risk officers that includes compliance measures based on
the relevant regulations and/or laws for your industry. Areas of risk and potential
liability should also be defined in the policy.
Messaging Compliance Overview
Exchange Server 2010 messaging compliance-related technologies such as
retention policies, Information Rights Management (IRM) integration, and to
a lesser extent message classification may be seen by end users as intrusions or
obstacles to doing their job, and these perceptions can result in the project failing
through no fault of the technology. Resistance such as this is the result of several
factors in the majority of cases:
An unclear or non-existent e-mail policy
Insufficient (or non-existent) communication to end users regarding the
purpose of the new features
Lack of upper management sponsorship for the compliance initiative
Forcing a taxonomy or classification system on your end users that is so
rigid that it impedes their daily work
Policies that are so disruptive to daily work that users find ways to
get around them
All of the above
As with any technology implementation, if you design and present your messaging
compliance deployment as something that meets the needs of the organization, rather
than an obstacle to be overcome, the project is much more likely to be a success.
Designing and Implementing Messaging
Records Management
The messaging records management (MRM) technology in Exchange Server 2010 provides
the message retention capability discussed in the “Messaging Compliance Overview” section
of this chapter. This allows your organization as well as your individual users to retain or
remove messages as required for company policy compliance, government regulations, or
legal needs, as well to remove e-mail that doesn’t need to be retained, such as personal
e-mail or newsletter subscriptions. Removing messages that don’t need to be retained can
assist in controlling mailbox growth and the resources required to support that growth. When
the age limit for retention is reached, an e-mail can be deleted or archived, an event can be
logged, or the message can be flagged for user attention. When combined with message
classification, AD RMS integration, and transport rules, MRM can provide a comprehensive
e-mail compliance solution.
The MRM implementation in Exchange Server 2010 is composed of retention tags and
retention policies; retention policies are collections of retention tags, which are then applied
to mailboxes. We will cover retention policies in more detail in the “Retention Policies” section
of this chapter.
Automated Message Processing, Compliance, and Archiving
Managed folders and managed folder mailbox policies, the Exchange Server 2007
implementation of messaging records management, are also supported in Exchange
Server 2007. Managed folders can be migrated to retention policies; this will be covered in
detail in the “Migrating from Managed Folders to Retention Policies” section of this chapter.
Managed folders and retention policies represent two different approaches to messaging
records management. Managed folders can be used to apply retention settings to default
mailbox folders (for example, Inbox, Sent Items, and Calendar) and custom managed folders
created by the administrator; similar functionality can be implemented using retention
policies and retention policy tags. However, retention policy tags provide the added flexibility
of users being able to apply retention settings to individual mail items or folders they have
created in their mailboxes; with managed folders, a user is required to move an item to
a managed folder with the appropriate retention settings applied to it. By applying personal
folder retention policy tags to messaging items or folders, a user can retain her folder
structure and file her messaging data to her liking, and still apply the necessary retention
policies to the data. The various types of retention policy tags and their usage will be
discussed in more detail in the “Retention Policies” section of this chapter.
Outlook 2007 or earlier clients don’t include all of the required client
features and thus are not supported when a retention policy is assigned to the mailbox to
deliver the client experience. Outlook 2007 or earlier clients can be used if the applicable
retention policies do not include personal tags.
In addition, journaling is not presently available with retention tags, so if you require
journaling you will need to deploy new managed folders or retain your existing ones.
With either technology (managed folders or retention policies), your users are taking part
in the MRM process by categorizing their messages according to their content and associated
retention requirements. Conceptually, this categorization thought process is similar to that
for message classification. (Message classification will be discussed in further detail in the
“Designing and Implementing Transport Rules” section of this chapter.)
MRM requires an Exchange Server 2010 Enterprise Client Access License (CAL) for
every mailbox configured for MRM.
Retention Tags and Retention Policies
In Exchange Server 2010, retention tags and retention policies replace or supplement the
managed folder mailbox policies introduced in Exchange Server 2007. Exchange Server 2010’s
messaging records management strategy of retention tags and retention policies is illustrated
in Figure 8-1.
Designing and Implementing Messaging Records Management
Create Retention
Create Retention
Policies and Link
Retention Tags to
Retention Ploicies
Contoso Retention Policy
Apply Retention
Policies to
Contoso Retention Policy
Managed Folder
Assistant Runs
Managed Folder
Mailbox Processed
Deleted Items
My Project X Folder
FIGURE 8-1 Retention tags and retention policies in Exchange Server 2010
Retention Tags
Retention tags are definitions of retention settings that are applied to folders and/or
individual items within folders such as messages or other item types. These settings specify
the retention period for the item type, and what action is taken when the specified age
is reached; the age is calculated in days from the delivery date, or from the creation date
if the item wasn’t delivered but created within the mailbox. Retention tags differ from
managed folders in that users don’t have to file items in managed folders to satisfy retention
requirements; they can tag items and folders within their own folder structure.
Automated Message Processing, Compliance, and Archiving
The following actions can be specified when a message reaches its retention age:
Mark As Past Retention Limit Marks a message as past the limit, but does not
take any further action.
Move To Deleted Items Moves the item to the Deleted Items folder.
Delete And Allow Recovery Item is deleted, but can be retrieved from Deleted
Items Recovery within the deleted items retention period set on the mailbox database.
Permanently Delete The item is not recoverable from Deleted Items Recovery,
unless litigation hold is enabled for the mailbox.
Move To Archive The item is moved to the user’s configured archive mailbox.
Localized language settings can also be specified for your retention tag using the
New-RetentionPolicyTag or Set-RetentionPolicyTag cmdlets. Localized names are specified in the
form of the “ISO Language Code”:”Tag Name” with the LocalizedRetentionPolicyTagName; for
example, -LocalizedRetentionPolicyTagName EN-US:”Business Critical”. You can also specify localized
comments with the LocalizedComment parameter (for example, -LocalizedComment EN-US:”This
is a localized comment in U.S. English”). Localized text (LocalizedRetentionPolicyTagName and
LocalizedComment) is visible within Outlook 2010.
You can create three types of retention tags: retention policy tags, default policy tags,
and personal tags.
Retention policy tags (RPTs) apply retention settings to default folders within the mailbox,
such as Deleted Items, Sent Items, and Contacts. You cannot apply an RPT to individual items,
although you can apply a different tag to items within a folder with an RPT applied to it. In
addition, users can’t apply a different tag to a default folder.
You can create RPTs for the following default folders:
Deleted Items
Junk E-Mail
Sent Items
RSS Feeds
Sync Issues
Conversation History
Designing and Implementing Messaging Records Management
In addition to the preceding list, a default policy tag (DPT) can be created; when a DPT is
added to a retention policy and that retention policy is assigned to a mailbox, the tag settings
apply to all folders and items within the mailbox that do not have other tags assigned or
through inheritance on the folder.
A retention policy can only contain a single DPT.
Finally, you can create personal tags. When you create a personal tag and add it to
a retention policy, a user whose mailbox the policy has been assigned to can tag individual
items or non-default folders within his mailbox with that personal tag. The result is that
the settings defined within the personal tag are applied to the item or folder; if applied to
an item, the personal tag overrides other tags that may be assigned to the folder, or any
default policy tag applied to the mailbox. If applied to a non-default folder, the tag replaces
any tag previously assigned to that folder.
Personal tags cannot be applied to default folders.
In Exchange Server 2010 SP1, retention tags and retention policies can be created through
the Exchange Management Console (EMC). The New Retention Policy Tag Wizard is shown
in Figure 8-2. A default policy tag is created by selecting All Other Folders In The Mailbox as
the tag type in the wizard, whereas a personal tag is created by selecting Personal Folder.
Selecting any other tag type creates a retention policy tag.
FIGURE 8-2 The Exchange Server 2010 New Retention Policy Tag Wizard
Automated Message Processing, Compliance, and Archiving
Retention tags can also be created via the Exchange Management Shell (EMS); it is worth
noting that localized tag names and message class settings can only be configured through
the EMS.
A mantra to keep in mind for retention tags—especially personal tags, which are
visible to the end users as choices they can make—is keep it simple. If an excessive number
of retention tag choices are presented in the Outlook 2010 or OWA interface, the user will
be more likely to give up on her attempts to use them. The best approach is to design the
absolute minimum number of retention tags and retention policies required to meet the
needs of your corporate e-mail policy for the organization as a whole, keeping policies broad
enough to be used across as many mailboxes as possible. You can then use these policies
and tags as a baseline to design and deploy other retention policies for specific sections or
departments as required, while re-using retention tags where possible. This not only keeps
the Outlook or OWA interface uncluttered, but also greatly reduces your management
overhead. Although the technology will support creating hundreds of retention tags in
hundreds of retention policies, you will seldom have a good reason to do so.
Retention Policies
Retention policies are collections of retention tags that you apply to mailboxes to implement
retention settings for items and folders in those mailboxes. Retention tags cannot be applied to
a mailbox directly; they must be included in a retention policy, and that policy is then assigned
to a mailbox or mailboxes. A mailbox cannot be assigned more than one retention policy,
although retention tags can be added to or removed from a retention policy at any time.
A retention policy can be composed of:
One or more retention policy tags for default folders, although you can’t link more
than one RPT of a particular type (such as Inbox) to a particular retention policy.
One default policy tag.
Any number of personal tags, although it is recommended to have no more than 10
to keep it simple for users.
Once retention policies have been applied to mailboxes, those mailboxes are then processed
by the Managed Folder Assistant, which runs on mailbox servers and provisions retention tags
in mailboxes on a scheduled process (by default, from 01:00 to 09:00 (1 AM to 9 AM)). If you
have implemented database availability groups (DAGs) and you wish to modify the Managed
Folder Assistant schedule, be certain to modify it on all mailbox servers in the DAG to ensure
consistent behavior in the event of a database being activated on a different server.
Additionally, if you wish to have the Managed Folder Assistant process a mailbox
immediately, you can run the Start-ManagedFolderAssistant cmdlet. With no parameters, this
causes the Managed Folder Assistant to process all mailboxes on the local server. You can
target specific mailbox servers with the Identity parameter, or specify particular mailboxes
with the Mailbox parameter. The following example retrieves all mailboxes that resolve from
Designing and Implementing Messaging Records Management
the ambiguous name resolution (ANR) search on the string “Dav”; for example, David Jones,
Dave Barnett, Velimir Davidovski:
Get-Mailbox -Anr Dav | Start-ManagedFolderAssistant
Removing a retention tag from a retention policy does not remove the settings defined in
that tag from items in the mailboxes the retention policy has been applied to. The Managed
Folder Assistant continues to process items stamped with that tag, and the retention
parameters specified in the tag continue to be applied to those items. However, removing the
retention tag does make the tag unavailable to the user; the removed tag can no longer be
applied to items in the mailbox.
To remove the retention tag’s settings from mailbox items that have been stamped with
it, the retention tag must be deleted. Retention tags can be deleted from the Exchange
Server 2010 SP1 EMC, or with the Remove-RetentionPolicyTag cmdlet in the EMS.
Deleting a retention tag causes the Managed Folder Assistant to process
all items that have the removed tag applied and restamp them the next time the Managed
Folder Assistant runs. This may consume significant resources on your mailbox servers
depending on the number of mailboxes and mailbox items affected.
You can also disable retention tags in lieu of deleting them; this causes the Managed
Folder Assistant to ignore all items stamped with that tag rather than restamping them.
However, these items are still considered tagged, so any default policy tag applied to the
mailbox will not affect them; in effect, you have suspended retention for any items marked
with that retention tag. A retention tag is disabled by selecting Disable This Tag in the
Properties dialog box for the tag in EMC, or by setting the RetentionEnabled property to
$False using the Set-RetentionPolicyTag cmdlet in the EMS.
You can create a retention policy using the New-RetentionPolicy cmdlet or through the
Exchange Server 2010 SP1 EMC. Creation consists of specifying a name for the policy and
optionally adding retention tags to the policy and assigning the policy to mailboxes. The
name of the retention policy must be unique in the organization, and there should be existing
retention tags to link to the policy as it is created. Although it is possible to create a retention
policy with no retention tags linked to it, it is not recommended because an empty policy
applied to a mailbox may cause items in that mailbox to never expire.
Retention policies are created in the Exchange Server 2010 SP1 EMC by navigating to the
Mailbox node under Organization Configuration and then selecting New Retention Policy
from the Actions pane to start the New Retention Policy Wizard. The New Retention Policy
Wizard is shown in Figure 8-3.
Automated Message Processing, Compliance, and Archiving
FIGURE 8-3 The New Retention Policy Wizard
The same retention policy example shown in Figure 8-3 can also be created in the EMS
using the New-RetentionPolicy cmdlet:
New-RetentionPolicy "Contoso RP - VPs" -RetentionPolicyTagLinks "Contoso R&D Projects"
After a policy is created and retention tags have been linked to it, you can apply that policy
to mailboxes; no single mailbox can have more than one policy applied to it at the same time.
Retention policies are applied using the Set-Mailbox cmdlet with the RetentionPolicy parameter.
They can also be applied through the properties of the retention policy or the Messaging
Records Management properties of a mailbox in the Exchange Server 2010 SP1 EMC. The
Messaging Records Management properties dialog box of a mailbox is shown in Figure 8-4.
FIGURE 8-4 Applying a retention policy to a mailbox
Migrating from Managed Folders to Retention Policies
Migrating from managed folders to retention tags and retention policies is essentially
a three-step process:
Create retention tags based on the existing managed folders and their managed
content settings.
Designing and Implementing Messaging Records Management
Create a retention policy and link the retention tags created in Step 1 to this policy.
Apply the retention policy to mailboxes.
Rather than creating a retention tag and manually defining retention settings to match
the managed folder and managed content settings to be replaced, you can migrate
the functionality of a particular managed folder to a retention policy tag as the tag is
created. A retention policy tag can be created from an existing managed folder using the
New-RetentionPolicyTag cmdlet with the ManagedFolderToUpgrade parameter, or by using
the Port From Managed Folder To Tag Wizard in Exchange Server 2010 SP1. This wizard is
shown in Figure 8-5.
FIGURE 8-5 The Exchange Server 2010 SP1 Port From Managed Folder To Tag Wizard
If you create a retention tag by porting an existing managed folder with EMC or
EMS, the tag created is automatically applied to the corresponding managed folder.
Creating retention policies was covered in detail in the “Creating a Retention Policy”
section of this chapter; you can create retention policies using the New-RetentionPolicy cmdlet
or by using the Exchange Server 2010 SP1 EMC. Applying a retention policy to mailboxes was
covered in the “Applying a Retention Policy to Mailboxes” section of this chapter.
Retention Hold
A mailbox can be placed on retention hold when the user is absent for an extended period
of time with no access to e-mail; this retention hold can be indefinite, or have scheduled
start and stop dates and times. This temporarily suspends retention policy processing for
that mailbox, so that messages are not deleted or moved to the user’s personal archive
before he has an opportunity to review them on his return. A retention comment can also be
configured; this comment can inform the user about the retention hold, including when the
hold is scheduled to start and end. Retention comments are displayed in supported Outlook
clients (Outlook 2010 and later), and can be localized so that the user sees the comment in
his preferred language. Retention comments are also used for litigation hold, as discussed in
Automated Message Processing, Compliance, and Archiving
the “Litigation Hold” section of this chapter, and are displayed in the Outlook 2010 Backstage
view as shown in Figure 8-13.
A retention hold can be configured on a mailbox via the Exchange Control Panel or the
EMC. In the EMC, they are configured by accessing the Properties dialog box for the mailbox
and then accessing the Messaging Records Management properties from the Mailbox
Settings tab as shown in Figure 8-6.
FIGURE 8-6 Configuring a retention hold via the EMC
Managed Folders
Although they are de-emphasized in Exchange Server 2010, Managed Folders are
another technology that provides MRM; it is recommended that you migrate any existing
Managed Folders to retention policies, and that you deploy retention policies for new
MRM implementations.
Managed Folders are composed of the following components:
Managed folders (default and custom)
Managed content settings
Managed folder mailbox policies
Managed Folder Assistant
Managed Folders Requirements
A mailbox must reside on an Exchange Server 2010 or Exchange Server 2007 computer to
be able to apply a managed folder mailbox policy to it. Mailboxes with a managed folder
mailbox policy applied to them can be accessed via Outlook 2010, Outlook 2007, Outlook
2003 SP2, Exchange Server 2010 Outlook Web App, and Exchange Server 2007 Outlook Web
Access; versions of Outlook older than Outlook 2003 SP2 are not supported. Outlook 2003
SP2 clients will not have access to all the features that are available to Outlook 2007 or higher
Designing and Implementing Messaging Records Management
clients, although they can access the mailbox. For example, they do not see any managed
folder comments that have been configured by the administrator.
Deploying Managed Folders
With a defined corporate e-mail policy to use as a framework, your managed folders can be
planned and deployed. The following steps are involved in deploying managed folders:
Create managed folders.
Create managed content settings for the managed folders.
Define managed folder mailbox policies.
Apply managed folder mailbox policies to mailboxes.
Configure the Managed Folder Assistant (optional).
Managed folders are created and then managed content settings are applied to them,
as required to satisfy your corporate e-mail policy. Managed folders are Active Directory
objects holding properties for defined default and custom folders within a mailbox that
the content settings are applied to. Custom folders are presented in the user’s mailbox in
a discrete folder hierarchy under a top-level folder named Managed Folders. An example
of a requirement that managed folders can satisfy is if your corporate e-mail policy states
that messages pertaining to client projects are retained for three years, whereas messages
containing privacy data as defined by legislation are retained for 30 days. To satisfy this
type of requirement, you can create two managed custom folders with defined retention
periods of 3 years and 30 days respectively. Users then file the appropriate messages in each
custom folder, and the Managed Folder Assistant applies the defined retention settings to the
messages in those folders.
Default folders are folders created in a user’s mailbox by default with or without MRM
implemented. These folders include the Inbox, Sent Items, and Deleted Items folders. Within
managed folders, a managed default folder named One-Year Retention of (for example)
type Inbox can be created and managed content settings applied to it. When this managed
folder is included in a policy and assigned to a user, the user’s Inbox folder is subjected to the
retention settings defined for that managed default folder.
Managed default folders are always displayed in the user’s mailbox with the
standard default name. For instance, in the example outlined earlier, because the folder is
of the Inbox type, users with the One-Year Retention folder assigned to them would see
the folder in their mailbox as Inbox; the One-Year Retention name assigned to the folder
when it was created is not visible to them.
In addition, you can assign only one managed default folder of any particular type, such
as Inbox, to a managed folder mailbox policy, and only one managed folder mailbox policy
can be assigned per mailbox.
Automated Message Processing, Compliance, and Archiving
Managed custom folders are created solely for MRM purposes, and appear in a mailbox’s
folder list separately from default folders, under a special default folder named Managed
Folder. Created and assigned to users or groups of users through the use of a managed folder
mailbox policy, these folders display in Outlook 2007 or higher with a special folder icon, as
shown in Figure 8-7. The managed folders are displayed similarly in Exchange Server 2010
Outlook Web App.
FIGURE 8-7 A managed custom folder in Outlook 2007
To create a managed custom folder named Contains Privacy Information using the EMS,
use the following:
New-ManagedFolder -Name 'Privacy Act' -FolderName 'Contains Privacy Information'
-StorageQuota 'unlimited' -Comment 'Email content containing privacy information; to be
retained for 90 days'
After creating managed default and custom folders, the next step in your managed folder
implementation is defining managed content settings for those folders. These settings
manage the life cycle of items in users’ managed folders by controlling retention periods
and applying actions to content when the retention period has been reached. Relevant
content can also be journaled to a storage location outside the mailbox; journaling is
discussed in the “Designing and Implementing Message Journaling” section of this chapter.
You can define when the retention period starts in one of two ways:
When delivered for messages or the end date for calendar and recurring tasks
When an item is moved to the folder
Designing and Implementing Messaging Records Management
In addition, the following actions can be defined to occur at the end of the retention
Move to the Deleted Items folder
Move to a managed custom folder
Delete and allow recovery
Permanently delete
Mark as past retention limit
Managed content settings can also be configured to journal content placed in the
managed folder to another location; this location can be any destination that has an SMTP
e-mail address, including a mail contact or another Exchange mailbox. Text labels can be
assigned to messages as well to facilitate the preservation of classification information; they
can also enable automated sorting of journaled messages by the recipient. A journaled item
is attached as an unaltered copy to a new e-mail message: certain properties of the journaled
item are assigned as properties of the e-mail message they’re attached to. This enables
automatic sorting and review of the content.
The following EMS example creates managed content settings for the Contains Privacy
Information folder, using Retain For 90 Days as the name for the managed content settings
and configuring the retention period for 90 days:
New-ManagedContentSettings -Name 'Retain for 90 days' -FolderName 'Contains
Privacy Information' -RetentionAction 'MoveToDeletedItems' -AddressForJournaling
$null -AgeLimitForRetention '90.00:00:00' -JournalingEnabled $false
-MessageFormatForJournaling 'UseTnef' -RetentionEnabled $true -LabelForJournaling ''
-MessageClass '*' -MoveToDestinationFolder $null -TriggerForRetention 'WhenMoved'
After managed folders have been created, and managed content settings have been defined
for those folders, you can create managed folder mailbox policies and assign managed
folders to them.
Managed folder mailbox policies are logical groupings of managed folders that are used
for deployment and management purposes. These policies are applied to users’ mailboxes;
this, in a single operation, deploys all the managed folders contained in the policy to those
mailboxes. You can create as many managed folder mailbox policies as required, and each
policy can contain as many managed folders as necessary. Keep in mind, though, that any
one mailbox can be assigned only one managed folder mailbox policy.
The following example creates a managed folder mailbox policy consisting of the Contains
Privacy Information managed custom folder:
New-ManagedFolderMailboxPolicy -Name 'Privacy Information Compliance Policy'
-ManagedFolderLinks 'Contains Privacy Information'
Automated Message Processing, Compliance, and Archiving
After you have created managed folder mailbox policies and assigned managed folders to
them, these policies can be assigned to users. Policies can be applied to users via the EMS,
where you can script a solution that incorporates powerful selection and filtering criteria
to configure users in bulk and target specified groupings of users.
The following example retrieves all users whose title equals Human Resources Analyst,
then applies the Privacy Information Compliance Policy managed folder mailbox policy to
their mailboxes:
Get-User | Where-Object {$_.RecipientType -eq "UserMailbox" -and $_.Title -eq "Human
Resources Analyst"} | Set-Mailbox -ManagedFolderMailboxPolicy "Privacy Information
Compliance Policy"
As with retention policies, after you have assigned managed folder mailbox policies
to mailboxes, those mailboxes are then processed by the Managed Folder Assistant.
The Managed Folder Assistant is discussed in detail in the “Retention Policies” section of
this chapter.
Designing and Implementing Transport Rules
In Exchange Server 2010, transport rules provide the ability to apply e-mail and compliance
policies to messages as they flow through your organization, providing the controlled access
and information and process integrity capabilities discussed in the “Messaging Compliance
Overview” section of this chapter. Transport rules are configured and managed on
an organizational level as a component of the Hub Transport configuration.
Transport rules are composed of the following components:
Conditions Conditions consist of one or more predicates that define which portions
of a message to examine, and what criteria to use for identifying messages that the
rule is applied to. For example, the To: field could contain David Jones, or the subject
or body of the message could contain the phrase “Top Secret”. Most predicates require
a comparison operator (equals, does not equal, contains) and a value to look for.
Think of the conditions as the if portion of an if-then statement. Exchange Server 2010
includes new predicates that were not available in Exchange Server 2007, such as
messages sent to partners, if the sender and recipient’s specified Active Directory
attribute matches a defined value, or if a message is not marked with a message
classification. If no conditions are defined, the rule will apply to all messages unless
exceptions are defined.
Exceptions Exceptions are composed of the same components as conditions except
that they identify messages that transport rules should not be applied to. Exceptions
override conditions; a message identified by an exception will not have the rule applied
to it, even if it meets all of the conditions. Exceptions are optional; they are included
only if necessary.
Designing and Implementing Transport Rules
Actions Actions specify what to do with messages that meet the defined conditions
and do not match any exceptions in the rule. A large number of actions are available
for transport rules. Exchange Server 2010 includes new actions in addition to those
offered in Exchange Server 2007; for example, adding the sender’s manager as
a specific recipient type, forwarding the message to a specified address or manager
for moderation, or applying rights management protection with an AD RMS
template. AD RMS integration will be covered in more detail in the “Designing and
Implementing AD RMS Integration” section of this chapter. Actions are mandatory;
you cannot create a rule without defining at least one action, although you can define
multiple actions in the same rule.
Rules Agents
Rules agents are responsible for applying transport rules on Hub Transport and Edge
Transport servers. The Transport Rules agent applies rules on the Hub Transport, whereas the
Edge Rules agent performs this task on the Edge Transport server. Although these two agents
are comparable in function, they are each unique in the predicates and actions available to
them, the priority of the rule agent relative to other transport agents, and what transport
event the agent fires on.
Transport Rules Agent
The Transport Rules agent runs on the Hub Transport server, and fires on the
OnRoutedMessage transport event. Hub Transport rules are created and managed at the
Exchange organization level, stored in Active Directory, and processed on all Hub Transport
servers in the organization. This provides Exchange Server 2010 with the ability to consistently
apply a uniform set of rules across the entire organization, but because the rules are stored in
Active Directory, the availability of the rules across the organization is dependent on Active
Directory replication.
Edge Rules Agent
Transport rules are processed on the Edge Transport server by the Edge Rules agent, which
fires on the EndOfData transport event. The primary purpose of the Edge Transport role is to
act as an e-mail gateway between your internal Exchange organization and the Internet, so
it is an ideal place to apply antivirus and anti-spam checks and policy restrictions to inbound
messages, so that unwanted messages can be filtered out without consuming resources on
your internal Exchange servers.
Edge Transport rules can also be used to process outbound Internet e-mail for
policy and compliance purposes. However, you cannot apply disclaimers to outbound
Internet e-mail with Edge Transport rules; this must be done with Hub Transport rules.
Automated Message Processing, Compliance, and Archiving
Rules created on Edge Transport servers are stored in the Active Directory Lightweight
Directory Services (AD LDS) database, formerly known as Active Directory Application
Mode (ADAM), on each Edge Transport server. Rules configured on one Edge Transport
server are not replicated to other Edge Transport servers, regardless of whether EdgeSync is
configured. This means that if you want the same rules applied on multiple Edge Transport
servers, they must be configured on each Edge Transport server, although you can use the
Export-TransportRuleCollection and Import-TransportRuleCollection cmdlets to automate the
process. This requirement does provide you with the flexibility to configure unique rules on
each Edge Transport server, however, which can be desirable in many cases—for example, to
configure unique rules based on the Edge Transport server’s address or type of e-mail traffic
that it handles.
Creating Transport Rules
Transport rules can be created via the EMC, the ECP, or by using the New-TransportRule
cmdlet in the EMS. One significant difference in Exchange Server 2010 is that, unlike
with Exchange Server 2007, you no longer need to instantiate predicates and actions
with the Get-TransportRulePredicate and Get-TransportRuleAction cmdlets for use in the
New-TransportRule cmdlet. The Get-TransportRulePredicate and Get-TransportRuleAction
cmdlets now only list the predicates and actions available for use on the Hub Transport or
Edge Transport servers that you run the cmdlet on. In Exchange Server 2010, all the predicates
and actions are available as parameters for the New-TransportRule and Set-TransportRule
cmdlets, providing the means for you to create or modify a transport rule with a single
The predicates available on Exchange Server 2010 Hub Transport servers are outlined
in Table 8-1; the variables that can be configured for each predicate are indicated in italics.
These predicates are listed by their display names as they appear in the New Transport Rule or
Edit Transport Rule wizards in the Exchange Server 2010 EMC.
TABLE 8-1 Hub Transport Rule Predicates
From people
When any of the recipients
in the To field is a member
of distribution list
With a spam confidence
level (SCL) rating that is
greater than or equal to limit
From a member of
distribution list
When any of the recipients
in the Cc field is people
When the size of any
attachment is greater than or
equal to limit
From users that are inside
or outside the organization
When any of the recipients
in the Cc field is member of
distribution list
Marked with importance
Sent to people
When any of the recipients
in the To or Cc fields is
If the message is Message
Designing and Implementing Transport Rules
Sent to a member of
distribution list
When any of the recipients
in the To or Cc fields is a
member of distribution list
When the sender’s properties
contain specific words
Sent to users that are inside
or outside the organization,
or partners
Marked with classification
When the sender’s properties
match text patterns
Between members of
distribution list and
distribution list
When the Subject field
contains specific words
Not marked with a message
When the manager of any
sender is people
When the Subject field or
message body contains
specific words
When an attachment’s
content contains words
When the sender is the
manager of a recipient
When the message header
contains specific words
When an attachment’s
content matches text patterns
If the sender and recipient’s
Active Directory Attributes
are attribute value
When the From address
contains specific words
When an attachment is
When a recipient’s address
contains specific words
When the Subject field
contains text patterns
When a recipient’s address
contains text patterns
When the Subject field
or the message body
contains text patterns
When a recipient’s
properties contains
specific words
When the message
header matches text
When a recipient’s
properties contains text
When the From address
matches text patterns
When any of the recipients
in the To field is people
When any attachment file
name matches text patterns
The predicates listed in Table 8-1 also have equivalent exceptions that can be
configured in the New Transport Rule and Edit Transport Rule wizards, as well as with the
New-TransportRule and Set-TransportRule cmdlets. Exceptions are expressed as the predicate
preceded with ExceptIf. For example, the exception parameter for the FromMemberOf
predicate is called ExceptIfFromMemberOf. Because the same predicate object contains the
logic for use in a transport rule condition and exception, exceptions aren’t shown separately
when you use the Get-TransportRulePredicate cmdlet to list predicates.
The predicates available on Exchange Server 2010 Edge Transport servers are listed in
Table 8-2. The available predicates for Edge Transport rules are for the most part a subset of
Automated Message Processing, Compliance, and Archiving
the Hub Transport rule predicates, along with a couple of predicates that are unique to the
Edge Transport.
TABLE 8-2 Edge Transport Rule Predicates
When the Subject field contains specific words
When the Subject field or message body contains
specific words
When the message header contains specific words
When the From address contains specific words
When any recipient address contains specific words
When the Subject field matches text patterns
When the Subject field or the message body
matches text patterns
When the message header matches text patterns
When the From address matches text patterns
When any recipient address matches text patterns
With an SCL rating that is greater than or equal to limit
When the size of any attachment is greater than or
equal to limit
From users that are inside or outside the organization
As discussed in Chapter 14, “Upgrading from Exchange Server 2003 and Exchange
Server 2007,” Exchange Server 2010 supports many new transport rule predicates and
actions, and has changes to some predicates and actions from Exchange Server 2007.
Because Exchange Server 2007 Hub Transport servers can’t process these new and changed
predicates and actions, transport rules are stored in a different format and location
in Active Directory. Thus, any Exchange Server 2010–specific transport rules are only
processed when the message traverses an Exchange Server 2010 Hub Transport server.
In a coexistence environment with Exchange Server 2007 and Exchange Server 2010, any
changes to transport rules in Exchange Server 2007 or Exchange Server 2010 must be
applied to the other version as well. The methods and cmdlets to do this are discussed in
detail in Chapter 14.
Transport Rule Examples
In this section, we’ll discuss a few examples of transport rules used to meet compliance
Designing and Implementing Transport Rules
Disclaimers are typically used to provide warnings about unknown or unverified e-mail
senders or legal information, or for other reasons as determined by an organization. In
Exchange Server 2010, you now have the ability to use HTML for disclaimers to e-mail
messages that are processed on Hub Transport servers; this is in addition to the ability to
apply plain-text disclaimers, which was introduced in Exchange Server 2007. HTML tags can
also include images by using IMG tags; note, however, that these images are not embedded
in the message and so should be located on a Web server that is accessible to the e-mail’s
recipients. In addition, you should remember that Exchange Server 2007 Outlook Web
Access, Outlook Web App, and Outlook 2007 and later block external Web content (including
images) by default, so it is recommended to test your disclaimers to verify that the recipient’s
experience is what you are expecting.
With Exchange Server 2010, Active Directory attributes can also be added to disclaimers
(DisplayName, FirstName, LastName, Department, and Company). The attribute names are
replaced by the values from the sender’s Active Directory user account when the disclaimer
rule is triggered. The attribute is enclosed in two percent signs (%%) to use it in the disclaimer;
for example, to use the DisplayName attribute you include %%DisplayName%%.
Disclaimers can be appended or prepended to messages. When a disclaimer is appended
(the default), it is inserted at the bottom of the message thread; Exchange Server 2010 doesn’t
check whether disclaimers have been added previously. A prepended disclaimer is inserted
before the text of the newest message in the thread.
Disclaimers are configured as actions in Hub Transport rules; as mentioned in the “Edge
Rules Agent” section of this chapter, disclaimers cannot be configured using Edge Transport
The following EMS example creates a transport rule that applies a disclaimer using HTML
formatting to all messages sent to recipients outside of the organization:
New-TransportRule -Name ExternalDisclaimer -Enabled $true -SentToScope
'NotInOrganization' -ApplyHtmlDisclaimerLocation 'Append' -ApplyHtmlDisclaimerText
"<h3>Disclaimer Title</h3><p>This is the disclaimer text.</p>"
-ApplyHtmlDisclaimerFallbackAction Wrap
As discussed in the “Messaging Compliance Overview” section of this chapter, ethical walls
are used to block communication between specified departments or sections of your
organization. Although an ethical wall can encompass numerous methods of communication,
including telephone, instant messaging, and postal mail, in the context of e-mail an ethical
wall is implemented using transport rules in Exchange Server 2010. In a typical configuration,
when a message is sent that matches the conditions defined in the transport rule, Exchange
Server 2010 rejects the message and returns a non-delivery report (NDR) to the sender
informing them that the message was rejected due to policy restrictions. This NDR can be
modified by customizing the delivery status notification (DSN) code used to provide the
Automated Message Processing, Compliance, and Archiving
sender with specific instructions or hypertext links to inform the sender of the policies or
regulations that prevented delivery.
The primary purpose of an ethical wall is to prevent communication, so
when implementing the transport rule for the ethical wall it is crucial to properly define the
scope (conditions and exceptions) of the rule. An improperly defined scope can potentially
block all messages sent to or from all recipients or senders in your organization.
The following example shows how to create a transport rule that implements
an ethical wall using the EMC. This example specifies a new, custom DSN code in the
RejectMessageEnhancedStatusCode property:
New-TransportRule "Sample Ethical Wall" -Enabled $true -BetweenMemberOf1 [email protected] -BetweenMemberOf2 [email protected] -ExceptIfFromMemberOf
[email protected] -RejectMessageReasonText "Sample Rejection Message"
-RejectionMessageEnhancedStatusCode '5.7.228'
This example then creates the custom DSN code and its specified text that is returned to
the sender with the DSN code:
New-SystemMessage -DsnCode 5.7.228 -Internal $true -Language En -Text "A message was
sent that violates company policy #123. For more information, please contact the
Compliance department."
Designing and Implementing Message Journaling
Archiving refers to reducing the amount of data in a user’s primary mailbox by moving it to
different storage (another mailbox, in the case of Exchange Server 2010 archiving); journaling
is the ability to record all e-mail communications in an organization for archival purposes to
meet with compliance and regulatory requirements. We’ll discuss archiving in detail in the
“Designing and Implementing Archiving” section of this chapter.
Although a specific regulation may not specifically require journaling, journaling may
achieve compliance under certain regulations. One example is corporate officers in a
financial sector that may be held liable for the claims made to their customers by their
employees. To verify that the claims are accurate, a system can be set up where a portion
of employee-to-client communications is regularly reviewed by managers on a quarterly
basis to verify compliance and approve employees’ conduct. When every manager has
formally reported approval to the corporate officer, the corporate officer can, on behalf
of the company, report compliance to the regulating body. E-mail messages are likely one
type of the employee-to-client communications reviewed by managers; in this case, all
e-mail messages sent by client-facing employees can be collected by journaling. Other client
communications that may also be subject to regulation, and thus monitored, include faxes
and telephone conversations; journaling all classes of data in an enterprise is an ability that is
a valuable functionality of the IT architecture.
Designing and Implementing Message Journaling
Journaling can be a requirement in particular regions or industries because of
governmental regulations such as the European Union Data Protection Directive (EUDPD),
Sarbanes-Oxley Act of 2002 (SOX), and the Securities and Exchange Commission Rule 17a-4
(SEC Rule 17a-4). Because these are regulatory or business issues, journaling requirements for
your Exchange Server 2010 environment are best determined through consultation with your
organization’s compliance and security staff.
Journaling is implemented in Exchange Server 2010 via the Journaling agent and journal
rules, and the output from the Journaling agent is journal reports—one report for each
message that is journaled; this output is stored in designated journaling mailboxes (one
mailbox per journal rule). We will discuss each of these concepts in detail in the following
sections of this chapter.
Journaling mailboxes can contain sensitive data, so access to these
mailboxes should be tightly controlled and monitored.
Journaling Agent
The Journaling agent is a transport agent focused on compliance; it processes messages
on Hub Transport servers. The Journaling agent fires on the OnSubmittedMessage and
OnRoutedMessage transport events. The Exchange Server 2010 Journaling agent is a built-in
agent; agents of this type are not included in the output of the Get-TransportAgent cmdlet.
The Journaling agent in Exchange Server 2010 provides two types of journaling:
Standard journaling Standard journaling is configured on a per-mailbox database
basis and allows the journaling of all messages sent to and from mailboxes located
on the targeted mailbox database. You must configure journaling on all mailbox
databases in the organization to journal all messages in the organization.
Premium journaling More granular journaling is accomplished by using
premium journaling with journal rules. You can configure journal rules to match your
organization’s needs by journaling individual recipients or members of distribution
groups instead of journaling all mailboxes residing on a mailbox database. An
Exchange Enterprise client access license (CAL) is required to use premium journaling.
Both types of journaling store their configuration information in Active Directory where
it is read by the Journaling agent and applied to the appropriate database in the case of
standard journaling, or recipient in the case of premium journaling. The journaling rules used
with premium journaling are also stored in Active Directory and accessed by the Journaling
agent from there.
Standard journaling is implemented on a mailbox database using the Set-MailboxDatabase
cmdlet and specifying the journaling mailbox with the JournalRecipient parameter;
the journaling mailbox is the mailbox used to store the journal reports generated by the
Journaling agent. Standard journaling can also be configured with the EMC on the properties
of the mailbox database, as shown in Figure 8-8.
Automated Message Processing, Compliance, and Archiving
FIGURE 8-8 Implementing standard journaling on a mailbox database
Premium journaling is implemented with journal rules on an organizational level as a
component of the Hub Transport configuration, similar to transport rules. You can start
the New Journal Rule Wizard from the Actions pane of the Hub Transport organization
configuration, as shown in Figure 8-9. Exchange Server 2010 SP1 also introduced the ability
to create journal rules from the ECP.
FIGURE 8-9 Creating a journal rule
Journal Reports
The output generated by both standard and premium journaling is a journal report; this
is the message generated by the Journaling agent when submitting a message to the
journaling mailbox. The original message matching the journal rule is attached unaltered to
the journal report. Information from the original message such as the sender e-mail address,
message subject, message-ID, and recipient e-mail addresses is included in the body of the
Designing and Implementing Message Journaling
journal report. This is the only journaling technique supported in Exchange Server 2007
and Exchange Server 2010, and is referred to as envelope journaling.
Exchange Server 2010 also supports journaling Information Rights Management
(IRM)–protected messages. When IRM support is configured, Journal Report Decryption can
include a clear-text copy of the message as an attachment to the journal report, along with
the original IRM-protected message. Any IRM-protected attachments are also decrypted,
provided that the attachment was protected at the same time as the message.
Journaling and Distribution Lists
Thierry Demorre
Senior Director, Avanade, USA
xchange Server 2010 Hub Transport servers have a default value for the
distribution list chipping size (how many recipients are processed when
expanding the DL to start sending messages as soon as possible) of 1,000. So if a DL
has 1,001 members, Exchange will send two messages, one with 1,000 recipients
and one with 1 recipient, which will translate into two journal reports being
generated. Some companies consider this to be non-compliant because neither of
the two messages accurately captures the envelope recipients.
In this case, the only option is to bump up the ExpansionSizeLimit setting in the
edgetransport.exe.config file on the Exchange Server 2010 Hub Transport servers to
a value that will exceed the maximum DL size in the enterprise or whichever one the
legal department is monitoring; this setting should be changed on all Hub Transport
servers in the environment to ensure consistency. This setting has no significant
performance implication because the DL has to be expanded anyway; the only
difference between expanding a 50,000-member DL with ExpansionSizeLimit set
to 1,000 and with ExpansionSizeLimit set to 50,000 is that in the former 50 messages
would be sent, whereas in the latter only 1 message would be sent but after the
time required to expand the 50,000 members.
Journal Rules
The journal rules used by premium journaling are composed of three components:
Journal Rule Scope The scope determines which messages are to be journaled:
Internal A journal rule with an internal scope targets messages sent and received
by recipients inside the organization.
External Setting an external scope targets the journal rule on messages sent to
or received from recipients outside the organization.
Global A global scope targets all messages that pass through the Hub Transport
server, whether external or internal.
Automated Message Processing, Compliance, and Archiving
Journal Recipients The journal recipient specifies the SMTP address of the recipient
to be journaled; specifying a journal recipient causes all messages both sent to or from
that recipient to be journaled.
Journaling Mailbox The journaling mailbox is used to store the journal reports
generated by standard or premium journaling.
You can also opt to journal or to not journal messages containing voicemail messages
and missed call notification messages generated by Unified Messaging. However, messages
containing faxes that have been generated by a Unified Messaging server are always journaled;
this is true even if you have specified to not journal voicemail and missed call notifications.
Designing and Implementing Personal Archives
Exchange Server 2010 introduces an integrated archive solution named personal archives; this
solution provides an alternative to personal store (.pst) files, providing you with the means
to phase out these files by importing them to the personal archive associated with the user’s
mailbox. Eliminating .pst files rids you of the many headaches associated with them:
Access from file shares is not supported.
They can be challenging to deal with during a legal or regulatory discovery request.
(Searching .pst files scattered across file servers, laptops, desktops, and removable
storage can be difficult if not impossible.)
A personal archive is a mailbox that can be used for alternative storage, and is optionally
created when the user’s primary mailbox is created, or it can be enabled on an existing
mailbox. The personal archive is accessible by the user in Outlook 2010, Exchange Server 2010
OWA, or Outlook 2007 (with the appropriate updates). In addition, the personal archive is not
accessible to offline clients, such as Outlook in cached mode; this may be seen as a limitation
to some users who have grown accustomed to having their .pst files available on their local
computer. Enabling a personal archive for an existing mailbox is shown in Figure 8-10.
Exchange Server 2010 personal archives functionality requires an Enterprise CAL
for each mailbox configured with a personal archive.
FIGURE 8-10 Enabling personal archive for an existing mailbox
Designing and Implementing Personal Archives
In the initial Exchange Server 2010 release, the personal archive was
restricted to the same database the user’s primary mailbox resided on; however, in
Exchange Server 2010 SP1 the archive mailbox can be placed on any database in the
organization, or in Exchange Online.
When a new mailbox is created with the New Mailbox Wizard in the EMC, a personal
archive can be created on the Archive Settings page of the wizard as shown in Figure 8-11.
FIGURE 8-11 The Archive Settings page of the New Mailbox Wizard
When an archive mailbox is created, content is moved automatically from the
user’s primary mailbox to his archive based on the default archive policy if no retention
policy is assigned to the mailbox. If a retention policy is assigned to the mailbox, that
policy supersedes the default archive policy and items are moved to the archive based on
the assigned retention policy. Refer to the “Retention Tags and Retention Policies” section
of this chapter for details on configuring retention tags and policies.
The default archive policy is a retention policy composed of the retention tags outlined in
Table 8-3.
TABLE 8-3 Contents of the Default Archive Policy in Exchange Server 2010
Default two-year move
to archive
This tag applies to all items in the
mailbox that don’t have a retention tag
applied directly or are inherited from
the folder; items older than two years
are moved to the archive.
Automated Message Processing, Compliance, and Archiving
Personal one-year
move to archive
Items or folders assigned this tag are
automatically moved to the archive
mailbox after one year.
Personal five-year
move to archive
Items or folders assigned this tag are
automatically moved to the archive
mailbox after five years.
Personal never
move to archive
Items or folders assigned this tag are
never archived automatically.
The storage quotas for personal archives are set separately from the quotas on the
user’s primary mailbox, and are configured for unlimited storage by default; if unlimited
quotas are not suitable for your environment, the archive warning quota can be set in the
Archive Quota dialog box on the Mailbox Settings tab of the user’s mailbox properties
in the EMC. You can modify the archive warning quota as well as the archive quota with
the Set-Mailbox cmdlet using the ArchiveQuota and ArchiveWarningQuota switches.
The archive quota sets at what point the user will no longer be able to move items to the
personal archive.
The retention tags linked to the default archive policy are system tags created by
Exchange Server 2010 setup, and by default are not returned in the output of the
Get-RetentionPolicyTag cmdlet unless you specify the IncludeSystemTags parameter.
Multi-Mailbox Search
Multi-Mailbox Search (also known as a discovery search) in Exchange Server 2010 provides
your organization with the ability to respond to legal discoveries or other internal
investigations as required by facilitating discovery search across multiple mailboxes. The
ability to use Multi-Mailbox Search is delegated through Role-Based Access Control (RBAC)
using the management role group Discovery Management; RBAC is discussed in detail in
Chapter 16, “Managing Exchange.” Non-technical users who have been delegated to perform
discovery searches can perform these searches through the ECP, without requiring Exchange
administrative access or other elevated privileges.
Multi-Mailbox Search uses the Exchange Search content indexes, and queries are
constructed using the Advance Query Syntax (AQS), which is also used by Windows Search
and Instant Search in Microsoft Outlook 2007 and later, so that users delegated the Discovery
Management role can create queries using syntax they’re already familiar with.
Multi-Mailbox Search
A target mailbox must be specified when performing a discovery search; mailboxes of
the type discovery are the only targets that can be selected when you perform a discovery
search using the ECP. Exchange Server 2010 creates one discovery mailbox with the display
name Discovery Search Mailbox, but others can be created as necessary. Discovery mailboxes
can only be created in the EMS with the New-Mailbox cmdlet using the Discovery switch,
and by default a newly created discovery mail has no mailbox access permissions assigned. In
addition, by default discovery mailboxes are visible in address lists, but users can’t send e-mail
to them; delivery is prohibited with delivery restrictions.
Multi-Mailbox Search also relies on a system mailbox named SystemMailbox{e0dc1c2989c3-4034-b678-e6c29d823ed9}. This mailbox (like other system mailboxes) is not visible
in the EMC, nor does it appear in any address lists; the purpose of this mailbox is to host
metadata for the Multi-Mailbox Search functionality.
Litigation Hold
The litigation hold functionality in Exchange Server 2010 provides the means for your
organization to respond to impending litigation or internal investigations. When expectations
such as these arise, all records, including e-mail, relating to the litigation or internal
investigation are expected to be retained. Whereas one means of addressing this may be
to configure journaling, journaling can present additional challenges to IT personnel such
as database growth and performance implications (each message is sent twice). These
challenges can be especially significant for impending events such as litigation because the
full scope of the resultant discovery are likely not fully defined yet, which means that you may
have to configure a much larger group of mailboxes for journaling than will ultimately be
required for the actual discovery to ensure that you are compliant to avoid severe penalties.
Litigation hold addresses these issues by preventing items in the Recoverable Items folder
from being purged permanently while the litigation hold is in place. The Recoverable Items
folder replaces the dumpster in previous versions of Exchange and is covered in detail in
Chapter 12, “Backup/Restore and Disaster Recovery.”
In brief, though, when a user hard deletes an item (by pressing Shift+Delete
simultaneously) or empties her Deleted Items folder, the items are placed in the Deletions
subfolder of Recoverable Items; the contents of the Deletions subfolder are what is visible
through the Recover Deleted Items tool in Outlook or OWA; this is the only folder within
Recoverable Items whose contents are accessible by the user. When an item is deleted using
the Recover Deleted Items tool in Outlook or OWA, it’s moved to the Purges subfolder of
Recoverable Items, and is purged from this folder the next time the Managed Folder Assistant
runs; the Managed Folder Assistant is discussed in detail in the “Retention Policies” section of
this chapter. When a mailbox is placed on litigation hold, items are no longer purged from the
Purges subfolder. If a mailbox has been configured with a personal archive, when litigation
hold is enabled the deleted content in the archive mailbox goes into the Recoverable Items
folder of the archive mailbox.
Automated Message Processing, Compliance, and Archiving
A final subfolder of Recoverable Items is the Versions folder; again, this folder and its
contents are not visible to the user. The Versions folder is used for litigation holds; when
a mailbox is placed on litigation hold, any changes to certain properties on any items within
the mailbox causes a copy of the original item to be stored in the Versions folder in a process
called copy on write. The properties that initiate a copy on write are outlined in Table 8-4.
The behavior of retaining items in the Purges folder, and retaining copies of
modified items, can also be attained by enabling Single Item Recovery on a mailbox. When
Single Item Recovery is enabled, items are retained in the Purges folder for the duration of
the deleted items retention period configured on the mailbox (or on the mailbox database,
if it has not been set on the mailbox directly). When a litigation hold is configured on the
mailbox, items are retained in the Purges folder for the duration of the litigation hold,
regardless of the deleted items retention period set on the mailbox or database.
TABLE 8-4 Properties That Initiate a Copy on Write
Messages (IPM.Note*)
Posts (IPM.Post*)
Sent/Received Dates
Items other than messages and posts
Items in the default folder Drafts
Any change to a visible property, except the
Item location (when an item is moved
between folders)
Item status change (read or unread)
Changes to retention tag applied to
an item
None (items in the Drafts folder are exempt
from copy on write)
All items in the Recoverable Items folder, including items in the Purges
and Versions folders, are indexed by Exchange Search, and are discoverable using
Multi-Mailbox Search, even though the Purges and Versions folders and their contents are
not visible to the user.
Multi-Mailbox Search
Placing a Mailbox on Litigation Hold
A mailbox can be placed on legal or litigation hold by users who have been assigned the Legal
Hold Management role or been added to the Discovery Management RBAC role group; this is
accomplished through the ECP or EMC in Exchange Server 2010 SP1 or via the EMS using the
Set-Mailbox cmdlet with the LitigationHoldEnabled parameter set to $true; to remove a legal
hold, set the LitigationHoldEnabled parameter to $false. In Exchange Server 2010 RTM, legal
holds can only be configured via the EMS using the Set-Mailbox cmdlet.
In addition, if your organization requires that users are informed when a legal hold is
enabled, the Retention Comment property can be set as well; when configured, this property
provides a notification for both retention and legal holds. We covered retention holds in the
“Designing and Implementing Messaging Records Management” section of this chapter.
The following example enables a legal hold on a mailbox and configures a Retention
Comment to notify the user of the legal hold:
Set-Mailbox tamer.salah -LitigationHoldEnabled $true -RetentionComment "This mailbox
has been placed on legal hold; you will be unable to permanently delete any items until
further notice."
It may take up to one hour for the legal hold to take effect.
Figure 8-12 shows the same litigation hold being configured via the ECP.
FIGURE 8-12 Configuring a litigation hold via the ECP
Automated Message Processing, Compliance, and Archiving
The Retention Comment configured with the preceding example is displayed in
Outlook 2010, in the Backstage view, as shown in Figure 8-13. The Retention comment is
not visible in Exchange Server 2010 Outlook Web App.
FIGURE 8-13 Retention comment for a litigation hold as seen in Outlook 2010
Performing a Multi-Mailbox Search
A Multi-Mailbox Search can be initiated through the ECP, or by using the EMS, assuming you
have been added to the Discovery Management RBAC role group. If you are performing
a search across all mailboxes in your organization that may return a large number of items,
Exchange Server 2010 SP1 provides the option to estimate the search result size. This option
is selected initially by default, as shown in Figure 8-14; it is recommended that you keep
this selection, as this will provide you with an estimate of the size of the search results, thus
allowing you to determine beforehand that the disk volumes holding the mailbox database
and transaction logs have sufficient free space to hold the expected search results.
In addition, for searches that will return a large number of items Exchange Server 2010
SP1 also provides the Copy Only One Instance Of The Message option as shown in
Figure 8-13. This will reduce the size of the results by removing any duplicate messages from
the search results.
Multi-Mailbox Search
FIGURE 8-14 Creating a New Multi-Mailbox Search in the ECP
The following example creates a search using the EMS; this search covers the period
1 January 2010 to 31 December 2010, looks for e-mail items only, searches for e-mail that
contains the phrases “last quarter” or “Project Contoso” or the word merger, and returns
unsearchable items as well:
New-MailboxSearch -Name "Merger Search" -StartDate "1/1/2010" -EndDate "12/31/2010"
-TargetMailbox "Discovery Search Mailbox" -SearchQuery '"last quarter" OR merger OR
"Project Contoso"' -MessageTypes Email -IncludeUnsearchableItems -LogLevel Full
A search object is created in the Exchange Server 2010 system mailbox when you perform
a search; manipulating this object allows you to start, stop, modify, and remove the search.
The following parameters are applied when performing a discovery search:
Keywords Keywords and phrases can be specified to focus the search.
Messages To Or From Specific E-Mail Addresses You can limit your search by
specifying the senders or recipients of messages to search for. Senders or recipients
can be specified by e-mail address, display name, or domain (such as
Date Range Searches aren’t limited by date range by default, but you can specify
start and end dates to narrow the search. If you define a start date but no end date,
the latest results will be returned each time the search is restarted.
Mailboxes To Search You can scope the search to include all mailboxes in the
organization, or limit the search by specifying mailboxes to include. Distribution
Automated Message Processing, Compliance, and Archiving
groups can also be specified; this will include mailboxes that are members of the
distribution group.
Personal Archive Multi-Mailbox Search includes personal archives by default. If
you want to exclude personal archives, you must create or modify the search using the
EMS; this option is not available via the ECP.
Message Types Your search can be configured to include all message types or it
can be limited to selected types. You can select to search the following message types:
Instant messaging conversations
Attachments Attachment types supported by Exchange Search are included in the
search. Additional file types can be supported by installing search filters (also known
as iFilters) for that file type on the Mailbox servers.
Include Items That Can’t Be Searched You can specify items that can’t be
indexed by Exchange Search in the search results. Reasons for unsearchable items can
include file types for which no search filters are installed, filter errors, and encrypted
messages such as those encrypted by S/MIME.
Safe List Exchange Server 2010 setup creates a safe list of file types that contain
content that can’t be indexed by Exchange Search; mailbox items containing these
items are not returned in the list of failed items. These file types include image files
such as bitmaps and multimedia files such as .mp3 and .mpg files.
IRM-Protected Messages Messages protected using AD RMS can be indexed and
returned in search results if Exchange Server 2010 has been configured for AD RMS
integration. AD RMS is discussed in details in the “Designing and Implementing AD
RMS Integration” section of this chapter.
If Exchange Search fails to index an IRM-protected message, that item
is not returned in the failed items list. You can compensate for this by creating a second
discovery search to return messages with .rpmsg attachments by using the query string
Search results are copied to the discovery mailbox specified when the search was created,
in a folder with the same name as the search. Underneath this folder, subfolders are created
for each searched mailbox, provided the Copy Only One Instance Of The Message option has
Multi-Mailbox Search
not been selected for the search. These folders are named using the mailbox’s display name
and the date and time the search was created. In each mailbox folder, messages are copied to
a folder that has the same name as their location in the user’s mailbox. The following example
of this folder structure shows a search named Merger Search that returned results in the
Inbox of the primary mailbox of a user named Tamer Salah:
Merger Search > Tamer Salah -25/2/2010 9:57:10 PM > Primary Mailbox > Inbox
The search results as they appear in Outlook 2010 are shown in Figure 8-15. If the Copy
Only One Instance Of The Message option was selected for the search, then all results are
copied to a single folder; in this example, a single folder named Results and the date and time
the search was created would be created underneath the Merger Search folder.
FIGURE 8-15 Search results in the discovery mailbox
Finally, if a discovery mailbox other than the default Discovery Search Mailbox is specified
for the search, mailbox access permissions must be configured separately for authorized users
to access the mailbox. These users can access the mailbox with either OWA or Outlook. Access
to the default Discovery Search Mailbox is granted through adding the authorized user to the
Discovery Management RBAC role group.
Designing and Implementing AD RMS Integration
In this section, we will discuss the integration of AD RMS with Exchange Server 2010,
starting with an overview of the AD RMS technology in Windows Server 2008 and Windows
Server 2008 R2.
Automated Message Processing, Compliance, and Archiving
AD RMS Overview
AD RMS is information-protection or information rights management (IRM) technology that
provides organizations with the means to better safeguard sensitive information. It does
this by enforcing policy through applying persistent protection to the e-mail or document,
allowing the publishers of confidential e-mail messages and documents to control who can
view their content. This is done using public key technology using XrML (Extensible Rights
Markup Language)–based certificates.
AD RMS is not a replacement for your X.509 PKI implementation, even though
AD RMS is based on public/private key technology; the two are complementary, and
provide different solutions for different problems. In the same vein, deploying RMS does
not require you to implement a PKI certificate authority (CA).
Persistent content protection is the fundamental distinguishing feature of AD RMS that
differentiates it from other encryption technologies such as S/MIME or PGP. A user who has
opened an S/MIME encrypted e-mail message using his keys has complete control over the
message while he has it opened; he can forward it, cut/copy/paste the contents, print the
message, and so on. The persistent content protection provided by AD RMS means that
as well as when the material is unopened, the rights the user has over the content are also
explicitly defined and enforced while the user has the e-mail or document open. Those rights
also persist with the message whether it is in an Exchange Server 2010 mailbox, in a PST file,
or wherever else it may exist. The most important concept is that rights are enforced while
the message is opened, meaning that the recipient cannot forward, print, cut, copy, or paste
the message unless the explicit rights to perform these actions have been granted.
Users present valid Active Directory credentials to the AD RMS server and are then
granted a Rights Account Certificate (RAC—their RMS credentials). The AD RMS client on
the user’s computer also generates a certificate for the client computer, and the user’s RAC
is encrypted with this machine certificate. If the user moves to a different client computer,
another instance of her RAC is obtained from the RMS server, encrypted for the new client
In addition to the RAC, a user is also issued a Client Licensor Certificate (CLC). The CLC
enables the user to encrypt (protect) content without contacting the AD RMS server, to
facilitate working offline; offline publishing is the default behavior for the RMS client.
When an RMS-protected e-mail is received by a user, that user is provided a use license
issued by the RMS server which grants them rights for that e-mail. Use licenses are encrypted
with the user’s RAC and bound to a specific client computer with that client computer’s
machine certificate, similar to the user’s RAC. RMS-protected content can be encrypted to
a single user or to distribution groups.
The various certificates issued to users can be viewed in the user’s profile, including
RACs, CLCs, use licenses, and the machine certificate. Note that if the user only accesses
RMS-protected e-mail via Outlook Web App, these certificates won’t be stored in his local
Designing and Implementing AD RMS Integration
user profile and instead will be stored on the Exchange Server 2010 Client Access server. In
Windows 7, these certificates are located at %userprofile%\AppData\Local\Microsoft\DRM.
The components of an AD RMS implementation are outlined in the following list; all of
these components are required except for AD RMS templates. Templates are not required
for the base functionality, but may be required to use some of the features of AD RMS
integration with Exchange Server 2010.
Active Directory AD RMS uses Active Directory to authenticate and authorize
users as well as to look up group memberships for content protected to groups. This
is done by referencing the user or group’s SMTP addresses, including proxy addresses.
To reduce the number of Active Directory lookups performed by AD RMS, group
memberships are cached in SQL.
AD RMS cluster An AD RMS cluster is composed of one or more AD RMS servers.
The AD RMS server is a Windows Server 2008 SP2 or Windows Server 2008 R2
computer on which the AD RMS role has been installed. This role has a Web service
that handles the XrML-based licensing of rights-protected information, enrollment of
servers and users, certification of trusted entities such as users and computers, and
administration functions. The AD RMS server role requires the Microsoft Message
Queuing service, IIS, and ASP.NET; these required services are installed automatically
when the AD RMS role is installed.
Database server AD RMS uses a SQL Server database—either SQL Server 2000
SP4 and higher, SQL Server 2005 SP3 and higher, or SQL Server 2008 SP1 and higher.
A single-server AD RMS cluster can use the Windows Internal Database feature of
Windows Server 2008 or Windows Server 2008 R2 for testing purposes, but is not
recommended for use in a production deployment.
AD RMS client The AD RMS client software is an integrated component of Windows
Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2. For Windows
XP SP2, Windows Server 2003, and Windows Server 2003 R2, the SAD RMS client is a
separate download and install.
RMS-aware applications Applications must be AD RMS–aware to be able to use its
An application being AD RMS–aware means that:
It relies on the AD RMS client for encryption/decryption.
It enforces the rights defined in the publishing license for the document or e-mail.
It can directly or indirectly call the RMS Web services.
It is certified by Microsoft via an application manifest signing process.
From a client computer perspective, Office 2003 Professional and higher or Office 2007
Professional Plus and higher are supported out of the box for protecting content.
Office 2003 Standard and Office 2007 Professional can access RMS-protected content
Automated Message Processing, Compliance, and Archiving
only; they cannot access RMS-protect content. Outlook e-mail messages and Microsoft
Word, Microsoft PowerPoint, and Microsoft Excel files can all be RMS-protected, as can
XML Paper Specification (XPS)–based documents. RMS functionality can be extended
with third-party products into other applications and file formats, such as PDF, CAD/
CAM file formats, and BlackBerry Enterprise Server. Exchange Server 2010 is also AD
RMS–aware; in many ways, from the perspective of the AD RMS cluster, Exchange
Server 2010 is simply another client.
AD RMS templates AD RMS templates provide a predefined set of user/group
and rights combinations that facilitate the consistent application of RMS protection
to content. These templates are defined on the AD RMS server and stored in the SQL
database used by AD RMS. The AD RMS templates are also exported in XML files to
a location configured on the AD RMS cluster for use by AD RMS clients. These XML files
are used by clients to view and select the AD RMS template to apply to the content.
To be usable for end users, the AD RMS template XML files must be made available
to them.
AD RMS templates are best used sparingly to keep the AD RMS deployment
manageable and so that the list of options presented to end users is as short as possible.
As an example, an organization of more than 250,000 users uses AD RMS with fewer than
five templates for the entire organization.
AD RMS Templates
Although AD RMS templates (also known as distributed rights policy templates) are optional
for end users who are applying IRM permissions to documents or e-mail messages manually,
they are required for Exchange Server 2010 to apply IRM protection via either transport rules
or Outlook Protection rules.
Exchange Server 2010 uses AD RMS templates when applying IRM to e-mail messages. If
no templates have been defined by the AD RMS administrator, the built-in Do Not Forward
functionality can be used. Do Not Forward is a client-side template that grants edit, view,
reply, and reply all permissions to recipients of an e-mail message. This client-side template is
a built-in function of the AD RMS client, and is available to Outlook and Exchange Server 2010
as a selectable template for Exchange Server 2010 transport rules and Outlook Protection
rules, independent of whether AD RMS distributed rights policy templates have been created.
The components of an AD RMS template are as follows:
Template Identification The template identification defines the language or
languages of the template, the template name (displayed in the Permissions menu in
Outlook or Outlook Web App), and a template description (displayed to the recipient
of the IRM-protected e-mail). The template name and description are configured
separately for each language supported in the template.
Designing and Implementing AD RMS Integration
User Rights The user rights define what users or groups are granted permissions
by this template and what permissions those users or groups receive. You can have
multiple users or groups specified, with each entry receiving different permissions. For
example, All Employees could be granted Full Control, whereas Sub-Contractors may
be granted only View permissions.
Expiration Policy The expiration policy dictates how long content is accessible
by recipients. For example, the policy can be defined to not allow access after
31 December 2010, or to not allow access after 30 days. By default, the author of the
content always has access, even after the content has expired.
Extended Policy The extended policy dictates whether users can view content
using a Web browser add-on, or whether clients need to obtain a new use license
(contact the AD RMS cluster) every time content is consumed. Caution should be
used when configuring a template to require a new use license every time content is
consumed; this will increase network traffic and make the content unavailable to offline
users. By default, use licenses are cached with the IRM-protected content, so the client
only needs to contact the AD RMS cluster the first time content is consumed. Note
that requiring a new use license every time content is consumed means that Exchange
Server 2010 will be unable to pre-fetch use licenses for e-mail protected with that
Revocation Policy Using revocation policies provides you the ability to revoke
content protected using this template. This option is not typically used because it
requires additional administrative overhead and requires that the published revocation
list be always available to all clients when they attempt to obtain a use license for
content protected with this template. If the revocation list is unavailable, clients will be
unable to access content protected with this template, although users (content owners)
by default always have access to content they have created.
For AD RMS clients—including Exchange Server 2010—to use AD RMS templates, the
XML files associated with those templates must be made available to the clients. This is
accomplished with the following steps:
Log on to a server in the AD RMS cluster with an Active Directory account that is
a member of the local AD RMS Enterprise Administrators group on the server.
Start the Active Directory Rights Management Services management console from
Administrative Tools.
In the Active Directory Rights Management Services management console, expand the
AD RMS cluster in the left-hand pane and select Rights Policy Templates. In the Results
pane, click the Change Distributed Rights Policy Templates File Location link and then
select the Enable Export check box as shown in Figure 8-16. Enter the UNC path for the
file share to export the template files to and then click OK.
Automated Message Processing, Compliance, and Archiving
FIGURE 8-16 Configuring the templates file location for AD RMS
The file location specified should already exist, and the RMS service account
needs to have write permission to the file share. In addition, clients accessing the
template files from this location need to have at least read permission to the file share.
When the distribution point for the template XML files has been configured, you create
distributed rights policy templates using the Create Distributed Rights Policy Template
Wizard in the AD RMS management console as shown in the following steps:
Log on to a server in the AD RMS cluster with an Active Directory account that is
a member of the local AD RMS Enterprise Administrators group on the server.
Start the Active Directory Rights Management Services management console from
Administrative Tools.
In the Active Directory Rights Management Services management console, expand the
AD RMS cluster in the left-hand pane and select Rights Policy Templates. In the Actions
pane, click Create Distributed Rights Policy Template as shown in Figure 8-17 to start
the Template Creation Wizard.
Designing and Implementing AD RMS Integration
FIGURE 8-17 Starting the Create Distributed Rights Policy Template Wizard
On the Add Template Identification Information page of the wizard, shown in
Figure 8-18, click Add. Select the language for the template, enter an appropriate
name and description, and then click Add to apply the settings and return to the
wizard. Click Next.
FIGURE 8-18 Setting a language and name for a template
On the Add User Rights page of the wizard, click Add to add the appropriate user
or group to the template. Back on the Add User Rights page, highlight the added
entry and select the appropriate rights for the user or group as shown in Figure 8-19.
Click Next.
Automated Message Processing, Compliance, and Archiving
FIGURE 8-19 Adding user rights to an AD RMS template
On the Specify Expiration Policy page, configure the content expiration settings as
appropriate and click Next.
On the Specify Extended Policy page of the wizard, click Next.
Click Finish on the Specify Revocation Policy page to complete the wizard and create
the template.
AD RMS and Outlook
Some editions of Microsoft Office can create and consume (open) IRM-protected content,
whereas other editions can only consume content (read-only). Table 8-5 outlines the IRM
capabilities of the various Microsoft Office editions.
TABLE 8-5 Office Editions and IRM Content Protection and Consumption
Office 2003:
Office 2003:
Small Business
Student and Teacher
Word Viewer 2003
Excel Viewer 2003
PowerPoint Viewer 2003
Designing and Implementing AD RMS Integration
Office 2007:
Office 2007:
Small Business
Professional Plus
Home and Student
Word Viewer 2007
Excel Viewer 2007
PowerPoint Viewer 2007
Office Mobile (version 6.0 and higher):
Office 2010:
Office Mobile (version 6.0 and higher):
Office 2010:
Professional Plus
Home and Business
Professional Academic
Home and Student
Office Starter
AD RMS and Exchange Server 2010
Assuming that an AD RMS infrastructure has been established on the network, AD RMS
can be integrated with Exchange Server 2010 for automatic application of IRM through
transport rules and Outlook protection rules with Outlook 2010 defined by the Exchange
administrator, and for manual application with Exchange Server 2010 Outlook Web App and
Outlook 2003 or higher. Applying IRM to messages with Outlook uses the IRM functionality
built in to Outlook, and is independent of the AD RMS integration with Exchange Server 2010.
In Exchange Server 2010, if AD RMS is implemented, voicemail messages marked as Private
also have IRM protection applied to them.
In Exchange Server 2007 and Exchange Server 2003 OWA, IRM functionality was limited
to reading messages only; you could not create new IRM-protected messages or reply to
existing ones. In addition, this functionality was limited to Internet Explorer on Windows,
and the AD RMS client had to be installed on the computer if the operating system was not
Windows Vista, Windows 7, or Windows Server 2008 and higher. An IRM-protected message
as viewed in Exchange Server 2007 OWA is shown in Figure 8-20.
Automated Message Processing, Compliance, and Archiving
FIGURE 8-20 An IRM-protected message in Exchange Server 2007 OWA
Protecting Messages with AD RMS
For an e-mail message to be protected using Outlook 2003, Outlook 2007, or Outlook 2010,
the client computer requires the AD RMS client to be installed; if the client operating system
is Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2, the RMS
client is integrated with the operating system. The RMS client is a separate download and
installation if the client operating system is Windows XP, Windows Server 2003, or Windows
Server 2003 R2.
In addition, Exchange Server 2010 provides the capability for the end user to apply
IRM protection to new messages manually and reply to IRM-protected messages
via Outlook Web App, using Internet Explorer 7 and higher, Firefox 3 and higher, or
Safari 3 and higher, running on any client operating system. Figure 8-21 shows an
IRM-protected message in Exchange Server 2010 Outlook Web App; note that the
message displays correctly in the Preview pane, and that the Reply and Reply All
functionality is available.
Exchange Server 2010 also provides you with the ability to apply IRM protection
automatically through transport rules on Exchange Server 2010 Hub Transport servers
and Outlook Protection Rules. Transport rules are covered in detail in the “Designing and
Implementing Transport Rules” section of this chapter.
Designing and Implementing AD RMS Integration
FIGURE 8-21 An IRM-protected message in Exchange Server 2010
Although users can apply IRM protection to messages manually before they send them, they
may occasionally neglect to do so for messages that should be protected. Outlook protection
rules in Exchange Server 2010 can help in protecting your organization from information
leakage by applying IRM protection to messages automatically when they are sent from
Outlook 2010. When IRM protection is applied to a message, any attachments in supported
file formats have IRM protection applied to them as well. Because Outlook protection rules
are applied within Outlook, the client must be running Outlook 2010 because this is the only
version of Outlook that can use Outlook protection rules.
Outlook protection rules are similar in functionality to transport rules that apply IRM
protection, but with the following differences:
With Outlook protection rules, IRM is applied in Outlook 2010, before the message
leaves the user’s computer. Transport rules on Hub Transport servers apply IRM when
the message enters the transport pipeline.
The IRM protection applied with Outlook protection rules is also applied to the copy of
the message in the user’s Sent Items folder.
Users are aware if IRM protection is applied to a message with an Outlook protection rule;
when a message is protected by a transport rule, the sender has no indication of this.
If the Outlook protection rule allows it, users can choose to override the protection
applied by the rule. If the rule is overridden by the user, an x-header named
X-MS-Outlook-Client-Rule-Overridden is inserted in the message by Outlook 2010. By
default, users can override the Outlook protection rule unless
UserCanOverride is set to false.
Automated Message Processing, Compliance, and Archiving
Outlook protection rules can be used to automatically protect content in scenarios
where you do not want to enable your Exchange servers for IRM integration; for example,
when the Exchange infrastructure is hosted/managed by a third party. However, you need to
be aware of the following information if Exchange does not have RMS super-user permissions:
The Exchange server will not be able to perform content filtering or anti-virus
filtering on protected content.
Exchange Server 2010 will be unable to apply certain transport rule predicates or
actions—such as when the Subject field or message body contains predicates—or
being able to append disclaimers to messages.
Protected content will not be available through OWA, will not be journaled in clear
text, and will not be indexed or discoverable.
Outlook protection rules must be created using the New-OutlookProtectionRule cmdlet
in the EMS; the following example creates a new Outlook protection rule that applies the Do
Not Forward RMS template to messages sent to the Engineering distribution group:
New-OutlookProtectionRule -Name "Project X" -SentTo "[email protected]"
-ApplyRightsProtectionTemplate "Do Not Forward"
The following predicates can be used in Outlook protection rules:
FromDepartment This predicate compares the sender’s department attribute in
Active Directory to the department specified in the rule, and IRM protects the message
if there’s a match. This will cause all messages sent by (for example) the Research
department with Outlook 2010 to be IRM protected.
SentTo The SentTo predicate causes all messages sent to the specified recipient to
be IRM protected. For example, you can specify that all messages sent to the Finance
distribution group have IRM protection applied to them.
SentToScope This predicate allows you to specify that messages sent inside
or outside the organization be IRM protected. This can be combined with the
FromDepartment predicate; for example, you can create an Outlook protection rule
that directs that all messages sent by the Research department to internal recipients
have IRM protection applied.
When Outlook protection rules are created, they are automatically distributed to Outlook 2010
clients with Autodiscover and the Exchange Web Services on Exchange Server 2010.
If you want to block any e-mail clients that do not use Outlook Protection Rules, you
can implement blocking of all versions of Outlook except Outlook 2010 by using the
Set-CASMailbox cmdlet with the MAPIBlockOutlookVersions parameter.
Consuming IRM-Protected Messages
IRM-protected messages can be accessed with Outlook 2003, Outlook 2007, or Exchange
Server 2010 Outlook Web App, assuming that the recipient has been granted appropriate
RMS rights to the message. To enable IRM for Outlook Web App, the Federated Delivery
Designing and Implementing AD RMS Integration
Mailbox must be granted AD RMS Super Users privileges by adding it to the Super Users
group defined for the AD RMS cluster; the Federated Delivery Mailbox is a system mailbox
created by Exchange Server 2010 Setup. The configuration of AD RMS for Exchange
Server 2010 integration, including Super Users, is covered in detail in the “Configuring AD
RMS for Exchange Server 2010” section of this chapter.
Exchange Server 2010 SP1 Outlook Web App also provides the ability to access
attachments that are IRM protected using Web Ready Document Viewing.
Although Outlook Web App provides the ability to read and reply to IRM
protected messages, unlike Outlook and other Office applications it can’t prevent users
from performing screen captures by using Print Screen.
IRM for Outlook Web App and Exchange ActiveSync (EAS) is enabled by default, and
is available after AD RMS is configured and the Federated Delivery Mailbox is granted
AD RMS Super Users privileges. To disable IRM for OWA and EAS, you can use the
Set-IRMConfiguration cmdlet with the ClientAccessServerEnabled parameter:
Set-IRMConfiguration - ClientAccessServerEnabled $false
Conversely, to enable IRM for OWA and EAS, set the ClientAccessServerEnabled parameter
to true.
The Set-IRMConfiguration cmdlet is used to disable or enable IRM for Outlook Web App
for the entire organization. If you want to enable or disable IRM for certain Outlook Web App
users, you can accomplish this with Outlook Web App mailbox policies. IRM is enabled or
disabled using the Set-OwaMailboxPolicy cmdlet with the IRMEnabled parameter.
Transport and Journal Report Decryption
Exchange Server 2010 can also be configured to decrypt IRM-protected content, to allow
for content scanning, applying disclaimers, facilitating discovery searches, and allowing the
journaling of decrypted copies of messages.
Transport decryption provides the ability for you to enforce messaging policies access
on IRM-protected messaging content by allowing access to the content by agents in the
transport pipeline. When enabled, IRM-protected messages are decrypted by the Decryption
agent; only messages protected with the AD RMS clusters in your organization can be
decrypted. The Decryption agent is a built-in transport agent; built-in agents are not returned
in the output of the Get-TransportAgent cmdlet.
Messages that have been IRM protected using transport rules do not need to be
decrypted by the Decryption agent; the transport rules apply protection when fired
by the OnRoutedMessage event, whereas the decryption agent fires on the OnEndOfData
and OnSubmit transport events.
Automated Message Processing, Compliance, and Archiving
After the Decryption agent decrypts the message, it is available to custom
or third-party agents that are installed on the Hub Transport server so that these agents
can perform their actions on the message. Although the message is always encrypted again
before leaving the Hub Transport server, you need to test the behavior of these custom or
third-party agents before deploying them in a production environment.
For example, if the actions of a custom or third-party agent cause a new message to
be created and the original message to be attached to it, only the new message is
re-encrypted; the original attached message is left unencrypted. This means that the final
recipients of the new message have access to the original message in an unprotected state,
and can take any action they wish with it, such as cutting, copying, printing, or forwarding it.
If an error occurs while decrypting a message, or re-encrypting it before the message is
passed on, the Hub Transport server attempts the action twice more. If the third attempt fails,
the Hub Transport considers this a permanent error and takes the following action:
If the permanent error occurred during decryption and if transport decryption is
set to Mandatory, an NDR is sent that includes the encrypted message. If transport
decryption is set to Optional, no action is taken and the message is delivered even if
decryption fails.
An NDR is always returned if the permanent error occurs during re-encryption; this
NDR never includes the decrypted message.
To configure transport decryption, the Federated Delivery Mailbox must be granted
Super Users privileges for your AD RMS cluster; this is covered in detail in the “Configuring
AD RMS for Exchange Server 2010” section of this chapter. When Super Users privileges
have been configured, enable transport decryption using the Set-IRMConfiguration cmdlet.
The following example enables transport decryption and rejects messages that can’t be
decrypted, returning an NDR to the sender:
Set-IRMConfiguration -TransportDecryptionSetting Mandatory
The acceptable values for TransportDecryptionSetting are Mandatory, Optional, or Disabled.
If your organization uses premium journaling, any messages protected with IRM may need
to be journaled unencrypted to enable successful discovery of that content in the event
of a legal or regulatory discovery request. When enabled, journal report decryption saves
a clear-text copy of the IRM-protected message in the journal report along with the original
IRM-protected message.
Journal report decryption only supports premium journaling, and thus requires
an Exchange Enterprise client access license (CAL).
Designing and Implementing AD RMS Integration
The decryption of the IRM-protected message is performed by the Journal Report
Decryption agent, a built-in transport agent. This agent fires on the OnCategorizedMessage
event while transport rules protect messages with IRM on the OnRoutedMessage event,
before the Journal Report Decryption agent sees them. Thus, messages protected by
transport rules are decrypted again by the Journal Report Decryption agent. Similar
to transport decryption, the Journal Report Decryption agent only decrypts messages
IRM protected by the AD RMS cluster in your organization.
Generally, only sensitive information is protected with IRM, so when you enable journal
report decryption the journaling mailbox may contain sensitive information that is not
encrypted. Best practice thus dictates that access to the journaling mailbox be monitored
closely and access allowed only to authorized individuals.
As with transport decryption, the Federated Delivery Mailbox must be granted Super
Users privileges for your AD RMS cluster before journal report decryption can be enabled;
this is covered in detail in the “Configuring AD RMS for Exchange Server 2010” section of
this chapter. After Super Users privileges have been configured, journal report decryption is
enabled using the Set-IRMConfiguration cmdlet:
Set-IRMConfiguration -JournalReportEncryptionEnabled $true
Applying IRM with Transport Rules
Once IRM integration with Exchange Server 2010 has been implemented, the action Rights
Protect Message With RMS Template can be selected for a transport rule, as shown in
Figure 8-22. The RMS template selected can be any distributed rights policy template
configured on the AD RMS cluster or the Do Not Forward client-side template. IRM protection
can be selected as an action for a rule on a Hub Transport server only.
FIGURE 8-22 Applying IRM protection via a transport rule
Automated Message Processing, Compliance, and Archiving
Configuring AD RMS for Exchange Server 2010
Before you can use the IRM functionality in Exchange Server 2010, you must configure your
AD RMS infrastructure. Your AD RMS cluster must be Windows Server 2008 R2 or Windows
Server 2008 SP2 with hotfix 973247, and the AD RMS Service Connection Point (SCP) must
be registered in Active Directory. In addition, the AD RMS server certification pipeline must
be enabled and access granted to the Active Directory Exchange Servers group; this must be
configured on each server in your AD RMS cluster.
Finally, to enable IRM in Outlook Web App, IRM for Exchange Search, transport decryption,
or journal report decryption, the Federated Delivery Mailbox must be granted Super Users
privileges in the AD RMS cluster. The Federated Delivery Mailbox is a hidden system mailbox
that is created by Exchange 2010 Setup; the Active Directory account associated by this
mailbox is disabled by default.
You register the SCP for AD RMS by following these steps:
Log on to a server in the AD RMS cluster with an Active Directory account that
is a member of the local AD RMS Enterprise Administrators group on the server
and a member of the Enterprise Administrators group in Active Directory.
Start the Active Directory Rights Management Services management console from
Administrative Tools.
In the Active Directory Rights Management Services management console, right-click
the AD RMS cluster in the left-hand pane and select Properties. Click the SCP tab in the
properties dialog box, as shown in Figure 8-23, and then select the Change SCP check
box. Click OK to register the SCP and click Yes in the confirmation dialog box to apply
the changes and exit the Properties dialog box.
FIGURE 8-23 Registering the AD RMS SCP
Designing and Implementing AD RMS Integration
Configure the server certification pipeline in AD RMS for Exchange Server 2010 integration by
following these steps:
Log on to a server in the AD RMS cluster with an Active Directory account with local
administrative privileges.
Click Start, and then click Computer to open Windows Explorer. Navigate to
C:\Inetpub\wwwroot\_wmcs\Certification, right-click ServerCertification.asmx, and
select Properties to open the Properties dialog box.
In the ServerCertification.asmx Properties dialog box, click the Security tab and then
click Advanced. Click Continue on the Permissions tab of the Advanced Security
Settings For ServerCertification.asmx dialog box.
In the Advanced Security Settings For ServerCertification.asmx dialog box, select
the Include Inheritable Permissions From This Object’s Parent check box, as shown
in Figure 8-24, and then click OK twice to apply the change and return to the
ServerCertification.asmx Properties dialog box.
FIGURE 8-24 Setting inheritable permissions on ServerCertification.asmx
Back on the Security tab of the ServerCertification.asmx Properties dialog box, select
Continue to open the Permissions for ServerCertification.asmx dialog box as shown in
Figure 8-25.
Automated Message Processing, Compliance, and Archiving
FIGURE 8-25 Granting the Exchange Servers Group Access to ServerCertification.asmx
In the Permissions for ServerCertification.asmx dialog box, click Add and then add the
Exchange Server group from Active Directory, granting this group Read and Read &
Execute permissions to the file. Apply the changes, and then close all dialog boxes to
return to Windows Explorer.
Repeat Steps 1 through 6 on all other servers in the AD RMS cluster.
To use the IRM in Outlook Web App, IRM for Exchange Search, transport decryption, or
journal report decryption functionality in Exchange Server 2010, the Super Users feature
in AD RMS must be enabled and assigned to a group containing the Federated Delivery
Mailbox. There is only one Federated Delivery Mailbox per organization, and it is created
by the /PrepareAD process. If this mailbox is deleted or disabled, IRM functionality will not
work; the associated Active Directory account for the Federated Delivery Mailbox is disabled
by default. You can re-create the Federated Delivery Mailbox if necessary by running
/PrepareAD again.
Enable and configure the AD RMS Super Users feature by following these steps:
If a Super Users group is not already created, create a distribution group named
ADRMSSuperUsers and add the FederatedEmail.4c1f4d8b-8179-4148-93bf00a95fa1e042 user to this group.
Log on to a server in the AD RMS cluster with an Active Directory account that is
a member of the AD RMS Enterprise Administrators local group.
Start the Active Directory Rights Management Services management console from
Administrative Tools and expand the cluster in the left-hand pane.
Designing and Implementing AD RMS Integration
In the console tree in the left-hand pane, expand Security Policies and then select
Super Users. Click Enable Super Users from the Actions pane, as shown in Figure 8-26.
FIGURE 8-26 Enabling Super Users in AD RMS
Back in the Results pane, click Change Super User Group as shown in Figure 8-27. In the
Super Users dialog box, type in the e-mail address of the Super Users group created in
Step 1, or click Browse to select the group from Active Directory. Click OK to apply the
FIGURE 8-27 Setting the AD RMS Super Users group
If Super Users is already enabled for a group, and the Federated Delivery Mailbox
is later added to that group, it may take between 12 and 24 hours for the change to take
effect because AD RMS caches group memberships in SQL and only updates them from
Active Directory when this cache has expired.
Automated Message Processing, Compliance, and Archiving
Designing and Implementing Message Classifications
The typical organization has invested heavily in solutions protecting against threats from
inbound e-mail such as malware (viruses, worms, Trojans, and phishing, for example) and
spam. However, the compliance and intellectual property risks of internal and outgoing e-mail
have not generally been given much consideration. The retention policy and managed folder
technologies that provide messaging records management in Exchange Server 2010 can
aid in dealing with these issues for e-mail residing in mailboxes (at rest), but they depend to
a large extent on decisions made on the content of messages by end users and, in some cases,
administrators. These decisions typically focus on the designation of messages based on their
content, principally in the context of their intended use, audience, retention, and so on.
E-mail classification adds visual labels and metadata to e-mail messages to describe the
intended use of or audience for a message to enable processes to make decisions based
on those designations. The message sender typically applies the message classifications, as
a decision made on the content of the message before it is sent. These classifications typically
indicate the sensitivity, intended distribution, retention periods, or other designations, usually
as required by the organization. If deployed with some pre-planning, message classifications
can offer a crucial piece of an effective strategy for managing and controlling e-mail by
ensuring regulatory compliance and maintaining policy.
Unclassified, Confidential, and Secret are some examples of message classifications used
by organizations, whereas others may employ designations such as Non-Business, Partner
Confidential, Mergers and Acquisitions, Privacy Act, and so on.
As with retention tags, AD RMS templates, and managed folders, the number of message
classifications should be kept to a minimum. This aids in keeping the interface uncluttered for
end users, which will in turn encourage them to actually use this new technology.
In Outlook 2007, Outlook 2010, and Outlook Web App in Exchange Server 2010, the
message classification applied can display visual labels for the sender and the recipients of the
e-mail in the form of a user-friendly description of the classification.
Message classifications in Exchange Server 2010 are informational only;
they are not integrated with any transport rules or messaging records management
functionality. However, they can be used as a predicate in transport rules, and transport
rules can be configured to apply a message classification as an action.
In addition, Exchange Server 2010 message classifications set on a message are only
visible to the recipient when viewed in Outlook Web App, or with Outlook 2007 or
Outlook 2010; Outlook 2007 and Outlook 2010 require additional configuration to apply
and view Exchange Server 2010 message classifications.
When a user composes a message in Outlook Web App and Outlook 2007 and higher, the
message classifications configured in Exchange Server 2010 are listed in the Permissions dialog
Designing and Implementing Message Classifications
box, along with AD RMS templates, as shown in Figure 8-28. In this example, Privacy Act is
a message classification, whereas the rest of the entries in the list are AD RMS templates.
FIGURE 8-28 Selecting a message classification in Outlook Web App
Message classifications are created using the EMS and the New-MessageClassification
cmdlet. It is worth noting that the message classification selection seen in Figure 8-28 is just
the display name of the classification. You specify the classification’s display name with the
DisplayName parameter; this defines the label seen from the selection menu by the sender.
The SenderDescription parameter defines the description that is shown to the sender in the
composed message, as shown in Figure 8-29.
FIGURE 8-29 Message classification sender description in a composed message
You can configure separately the text displayed to recipients of a classified message with
the RecipientDescription parameter; the recipient description for the message composed in
Figure 8-29 as seen in Outlook Web App is shown in Figure 8-30. If the recipient description
is not configured, the text configured for the sender description is displayed.
FIGURE 8-30 Message classification as seen by an Outlook Web App recipient
Automated Message Processing, Compliance, and Archiving
Simplifying the End-User Experience
with Message Classifications
Ed Banti
Program Manager, Microsoft Corporation, Redmond, WA
ll too often organizations will attempt to place rigid or complex policies on
their end users in the name of governance, compliance, security, privacy, or a
whole collection of laws and regulations. For example, I’ve heard of organizations
that prompt their employees to classify every single e-mail and that process
involves understanding the definition of hundreds of classification tags and picking
the right one. I’ve also heard of organizations that give their employees complex
instructions on when to IRM-protect documents or when it’s appropriate to
S/MIME encrypt versus sign an e-mail. While the intent is to keep the organization
and employees out of trouble, this approach results in employee frustration and
ultimately leads to the “click the default” and ignore mentality, which is contrary to
the original goal and intent of the policy.
Instead of pushing complex rules to employees, organizations need to consider
ways to reduce confusion and streamline the process. An easy way to do this out of
the box in Exchange 2010 is via message classifications and transport rules. Message
classifications are informational policies that can be tagged (either manually or
automatically) to e-mail messages that can display a user-friendly description in
Outlook or OWA. These message classifications can then trigger transport rules in
the background. Take a look at the following example.
Contoso is a healthcare provider with patient information that needs to be kept
confidential. Today they instruct their employees to include a disclaimer on all
e-mails that contain patient data and they also require that these e-mails be
encrypted. Half the time, employees forget to do this or they only include the
disclaimer but don’t encrypt the mail. To simplify, Contoso creates a set of message
classifications: Patient Data, Financial Data, and Public. When an employee marks
and sends a message as Patient Data, a transport rule is triggered that automatically
adds the proper disclaimer to the message and protects the message using AD RMS
such that the content cannot be viewable outside of Contoso. For Financial Data
e-mail, a transport rule applies a different disclaimer and forces the message to be
moderated before the message can leave Contoso. This ensures that no financial
data is sent outside the company without approval.
As this example shows, you have access to simple and straightforward ways to use
message classifications to abstract complex policies and actions from employees
while encouraging them to properly handle and classify sensitive information.
Designing and Implementing Message Classifications
Dependencies of Message Classification
Active Directory and the messaging client used are the main dependencies of message
classification in Exchange Server 2010; we’ll go over each of these in turn in the following
Active Directory Configuration Container
As with all Exchange Server 2010 configurations, message classifications are stored in Active
Directory; in particular, in the Configuration container in the path Configuration/Services/
Microsoft Exchange/<Organization>/Transport Settings/Message Classifications/<Locale>.
The classifications can be verified using ADSI Edit (ADSIEdit.msc), as shown in Figure 8-31.
FIGURE 8-31 Message classifications in Active Directory
As inferred from what you saw in Figure 8-25, message classifications are locale-specific
(language-specific). This means that you can present several versions of the same
classification, so that different users see a version in their own language as determined by
their client locale settings. Creating localized message classifications is covered later in the
“Creating Localized Message Classifications” section of this chapter.
Messaging Client
The other primary dependency for Exchange Server 2010 message classifications is the
messaging client. As stated earlier, classifications are set by the message sender on outgoing
messages in Outlook 2007, Outlook 2010, and Exchange Server 2010 Outlook Web App and
are viewable by recipients only in those same clients.
Creating Message Classifications
in Exchange Server 2010
You can create the message classification shown earlier in Figure 8-24 using the following
New-MessageClassification -Name Privacy -DisplayName "Privacy Act" -SenderDescription
"This message contains personal information as described by the Privacy Act"
-RecipientDescription "This message contains private information of clients as defined
in the Privacy Act"
Automated Message Processing, Compliance, and Archiving
The common parameters used when creating new or configuring existing classifications
are listed in Table 8-6.
TABLE 8-6 Message Classification Common Parameters
This parameter specifies the display name for the
message classification. This display name is shown in
Outlook 2007, Outlook 2010, and Outlook Web App; it
is used to select the appropriate message classification
before a message is sent. The DisplayName parameter
must be 64 characters or fewer.
Provides an explanation to the sender what the
message classification is intended to achieve. This is
used by Outlook and Outlook Web App users to assist
in selecting the appropriate message classification
before sending a message. The SenderDescription
parameter must be 1,024 characters or fewer.
Displays text to the recipient explaining what the
message classification is intended to achieve. This
is seen by Outlook and Outlook Web App users
when a message with this classification is received.
The RecipientDescription parameter must be
1,024 characters or fewer. If this parameter is not
configured, the text set for SenderDescription is used.
This parameter allows you to localize the message
classification for different languages when a culture
code is specified. You also must also specify the Identity
parameter of the existing message classification when
you create a new locale-specific version. Values for
the Locale parameter are the string names listed in
the Culture Name column in the Microsoft .NET Class
Library class reference that is available at http://go
Specifies whether the message classification should
persist with the message if the message is forwarded
or replied to; the default value for this parameter is true.
Creating Localized Message Classifications
Localized versions of an existing message classification can also be created for
accommodating multilingual organizations. Exchange Server 2010 determines the language
of the recipient by examining the recipient’s mailbox when a message is classified and sent.
Designing and Implementing Message Classifications
If a message classification in the corresponding language is found in Active Directory, the
message has that classification attached to it by Exchange Server 2010. If there is no exact
language match, Exchange examines the recipient mailbox’s locale property to determine
the locale of the recipient. In the event of no match for the specific locale of the recipient,
Exchange Server 2010 looks for a version that is culture-neutral, such as es for es-MX,
(Spanish-Mexico) or fr for fr-CA (French-Canada). Finally, the default message classification is
used if no language-specific or culture-neutral match is found, regardless of its locale.
Localized message classifications are created with the New-MessageClassification cmdlet,
using the Identity parameter to identify the existing classification and the Locale parameter
to indicate the locale of the new classification. For example, to create a Spanish version of
a message classification named Privacy, you would use the following cmdlet:
New-MessageClassification Privacy -Locale es-ES -DisplayName "España Example"
-SenderDescription "Este es el texto de la descripción"
Configuring Message Classifications for Outlook 2007
and Outlook 2010
After your message classifications have been created and configured, a few more steps
are required to allow Outlook 2007 and Outlook 2010 users to be able to set message
classifications. You must export the classifications from Active Directory to an XML file, and
make this file accessible to the Outlook 2007 and Outlook 2010 clients. This is accomplished
with the Exchange Server 2010 EMS script named Export-OutlookClassification.ps1; this script
is located in the <install_drive>:\Program Files\Microsoft\Exchange Server\Scripts directory
on the server running Exchange Server 2010.
After the classification XML file is exported, Outlook 2007 and 2010 clients not only require
access to the file, but also require message classification to be enabled. This is done through
the registry by creating the three values shown in the following example:
You must change the above registry key to [HKEY_CURRENT_USER\Software\Microsoft\
Office\14.0\Common\Policy] for Outlook 2010 clients. This Policy key is not present by default
in Outlook 2007 or Outlook 2010, so it must be created. Table 8-7 outlines the registry values
configured as well as the purpose of each.
TABLE 8-7 Registry Values for Outlook 2007 and Outlook 2010 Message Classifications
This string value defines the location where the
classification XML file is stored. This can be any location
accessible to the Outlook 2007 client, including a network
Automated Message Processing, Compliance, and Archiving
To enable message classification functionality for the specified
user, set this DWORD value to 00000001. Message classification
functionality is disabled by setting this value to 00000000.
TrustClassifications should only be enabled for Exchange
Server 2010 users, and is enabled by setting this DWORD
value to 00000001. Message classifications between
users on Exchange Server 2003 are also supported by Outlook;
because Exchange Server 2003 doesn’t support or recognize
message classifications, the content and validity of the
message classifications is not guaranteed. In this case, disabling
TrustClassifications prepends the text “The sender claims:” to
the message classification. This prevents the recipients from
assuming incorrectly that their organization has processed the
classification. Disable TrustClassifications by setting this DWORD
value to 00000000.
The message classification XML file exported from Active Directory must be
distributed to Outlook 2007 and 2010 clients, and this presents some challenges about
where to store the XML file so that it is accessible to these clients.
Storing the XML file in a local path on the client computer ensures that message
classifications are available to the user when they are offline in cached mode; however, this
means that the file needs to be distributed to and updated on all of the client computers—
especially if classifications are modified or added/removed.
You can store the XML file on a network share so that it is maintained in only one location,
but this presents challenges for those users working offline in cached mode—they will be
unable to use the message classifications while working offline.
One solution to this challenge is to store the file on a network share and force that network
share to be available offline for all connected users (using Windows offline files). This
ensures that message classifications are available to end users at all times, while leaving
only one file location to maintain. When offline users connect to the corporate network
again, any changes made to the XML file will be updated in their offline files cache.
Assigning Message Classifications with Transport Rules
As we’ve seen, with Exchange Server 2010 and supported messaging clients you can provide
end users with the ability to assign message classifications to messages before they are sent.
In addition to this, you can automatically assign classifications to messages using transport
rules run by the Hub Transport role based on criteria you specify. As with any transport rules,
conditions are defined for the rule and then an action is set for the rule to take when the
Designing and Implementing Message Classifications
conditions are met; in this case, applying a message classification. As a case in point, you
could configure a transport rule to check for messages that contain a text pattern matching
a Social Security number, then apply a message classification named Privacy Act to ensure
compliance with regulatory and company policies.
Besides assigning classifications with transport rules, transport rules can also be created
that act on messages that have already been classified. One example is to prevent any
messages classified Company Internal from leaving the organization; another example
would be to apply IRM protection to messages classified Client-Attorney Privilege. What
this all means is that even though message classifications are only visible in Outlook 2007,
Outlook 2010, and Outlook Web App, your organization may still find them of value.
Additional Resources
Configure a Disclaimer: Exchange 2010 Help:
Titus Labs security and classification solutions videos, whitepapers, case studies,
datasheets, and other resources:
Exchange Server 2010 Compliance Capabilities:
Hold Me Now! How to Quickly Put a Retention Hold on 1,400 Employees Using
Microsoft Exchange 2007:
Exchange 2007 Assists Regulatory Compliance:
Single Item Recovery in Exchange Server 2010:
Part 1: How to Add a Disclaimer to Exchange Server 2007 E-mail: http://searchexchange,295582,sid43_gci1256759_mem1,00.html
Messaging Policy and Compliance:
Apply Exchange Server 2010 Message Retention Tags for E-mail Archiving:,295582,sid43_gci1379660,00.html
E-mail Retention Policies in Exchange 2010:
Understanding Information Rights Management:
Planning for Compliance:
Automated Message Processing, Compliance, and Archiving
Unified Messaging
Introduction to Unified Messaging
The Basics of Telephony
Exchange Unified Messaging Architecture
Planning for Unified Messaging 415
Deploying Unified Messaging
International Considerations of Unified Messaging
Managing Unified Messaging
Office Communication Server 2007 R2 Integration 436
xchange Server 2010 Unified Messaging bridges the gap between voice and
messaging, thus allowing your users to access their Exchange mailboxes using a
regular phone. Introduced with Exchange 2007, Exchange 2010 Unified Messaging now
provides an even more sophisticated implementation that needs to be carefully planned
to be implemented well.
This chapter is about designing, planning, and deploying the Unified Messaging (UM)
server role for your organization, including the telephony basics you need to understand
to configure the UM server role.
Additionally, the UM role is capable of being tightly integrated into an Office
Communication Server 2007 (OCS) or later implementation to provide not only voice
mail and Outlook Voice Access but also to provide an automated switchboard that can
be fully customized for your company’s needs.
This chapter is only important if you are planning on using the UM role, which
requires you to connect your telephony system to Exchange. If you do not plan to use it,
you can skip this chapter.
Introduction to Unified Messaging
Exchange 2010 Unified Messaging combines voice and e-mail messaging in the Exchange
Server store and integrates telephony systems with Exchange. Many companies manage voice
mail separately from e-mail. Usually, voice messages and e-mail exist as separate inboxes on
separate servers, and users access them using different tools. Frequently, each communication
tool requires a separate address list, which can make it difficult to keep all address lists
synchronized. Unified Messaging brings these tools together and offers an integrated store
and user experience for both voice mail and e-mail.
Exchange 2010 Unified Messaging provides the following core features:
Voice mail Also known as call answering, it enables the system to answer
the telephone and record a message when the user is unavailable.
Outlook Voice Access OVA provides users with access to their Exchange mailbox
from a phone. It enables you to use any telephone to retrieve e-mail, voice mail,
calendar, personal contacts, and to access the company directory. You can also create
messages to both internal and external recipients. With Exchange 2010 SP1 you can
also change the sorting of the messages—for example, you can play the oldest voice
mail first.
An excellent Quick Start Guide for Outlook Voice Access 2010 is available at
Play on Phone This feature lets a Unified Messaging–enabled user listen to
a voice message using a telephone instead of playing it over computer speakers
or headphones.
Voicemail Preview The Unified Messaging role uses Automatic Speech Recognition
(ASR) on newly created voice messages. When users receive voice mail, they receive
messages that contain the voice recordings along with a text transcription that
Unified Messaging creates from recordings. UM also learns from the individual and
will improve over time by using a grammar-generation algorithm for the most used
words per mailbox. This algorithm is performed by the mailbox assistant once a month.
Voicemail Preview is not available in all languages. Exchange 2010 SP1 increases the
accuracy of voice mail preview and also includes the ability to set the UM policy to
automatically send voice mail messages to Microsoft for analysis so that Voicemail
Preview can be improved, especially in languages other than English. SP1 also adds
additional languages such as European Spanish.
Protected voice mail Unified Messaging provides this functionality so that callers
can send private mail, which Microsoft Rights Management Services (RMS) protects.
Unified Messaging
However, Unified Messaging restricts users to only forwarding, copying, and extracting
the voice file from mail by applying the Do Not Forward template.
Auto Attendant Allows callers to look up a person and identify his or her extension
number from the organization’s global address list. With auto attendant you can also
create custom menus for callers, define different greetings based on the business
hours, describe to callers how to find the people they are calling, and connect callers
to the operator.
Call Answering Rules The user can configure a custom experience for incoming
callers by creating and customizing call-answering rules based upon different factors
such as time of day, free/busy status, Caller ID, and so on.
Message Waiting Indicator (MWI) Exchange Server notifies users of the presence
and number of new or unread voice mail messages on their phones.
Missed Call and Voice Mail Notifications via SMS Users can receive
notifications about missed calls and new voice messages on their cell phones in a text
message via the Short Messaging Service (SMS).
Calling Name Display Exchange 2010 SP1 enhances the support for displaying
caller names if your PBXs or IP gateways pass the information in their SIP INVITE. You
can identify that the name was passed from the PBX when you see the name in quotes,
such as Voice mail from “Joel Stidley”.
Behind the Scenes of Unified Messaging
Ankur Kothari
Senior Technical Product Manager, Exchange Server, Microsoft Corporation
reating a voice mail product in today’s world involves looking at how people
work today, which invariably differs from how voice mail solved a need in 1975.
Today, people rely on many communication technologies to achieve their business
needs—the telephone being only one of them.
What we learned from customers and our research was that users are overwhelmed
with information—information overload is a term we heard many times. Helping
solve this challenge is something that we hope Exchange Unified Messaging will
do, by placing voice mail in your e-mail Inbox and making it accessible in a number
of languages. We’ve done some great things in making a voice mail message very
similar to the e-mail experience by introducing speech-to-text technology, which
will create a text-based Voicemail Preview of a message—one of many new features
that will help users to be more productive in the now.
Introduction to Unified Messaging
The Basics of Telephony
Because Unified Messaging must be integrated into your company’s telephony solution,
it’s important to understand the most crucial terms and definitions to be able to follow
the discussions in this chapter.
If your company is already connected to Office Communications Server 2007 or
later with your telephone system, you don’t need to consider the details in the following
sections; Exchange 2010 will use OCS as the gateway.
Types of Telephone Systems
Three general types of business telephone systems can be integrated with Unified Messaging:
Centrex Phone System Phone companies lease a Centrex phone system (also
known as Central Office Telephone Exchange) to businesses. The Centrex phone
system uses the phone company’s central office (CO) exchange to route internal calls
to an extension. A new Centrex version called IP Centrex is available. With IP Centrex,
the organization does not rent phone lines from the telephone company’s CO. Instead,
the CO sends the phone calls through a VoIP gateway, which routes them over a VoIP
gateway or through the Internet. At the organization’s office, another VoIP gateway
translates the call to a traditional circuit-switched call.
Key Telephone System This phone system is similar to the Centrex system in that
the organization leases several phone lines from the telephone company. However,
with the Key Telephone System, each phone line connects to multiple telephones in
the organization. When someone calls the company, all phones ring that are associated
with that line. Businesses with Key Telephone Systems often arrange for someone to
answer incoming calls, and then announce the call to the correct recipient.
Some key telephone systems can work with UM if an IP gateway is added.
However, some less sophisticated systems may not work even if a supported IP gateway
is used. Make sure you contact your vendor before you try to use your key telephone
system with Exchange 2010.
Private Branch Exchange System A Private Branch Exchange (PBX) system
is different from the other telephone systems in that it typically has only a single
connection to the phone company and all call switching happens at the organization.
The connection to the phone company usually occurs through a T1 or E1 line, both
of which provide multiple channels to enable multiple calls over the same line, also
called trunk lines. The PBX routes internal phone calls and those between external
and internal users. In a PBX system, each user has a telephone extension. When an
internal user places a call to another internal user, she uses only the extension number,
and the PBX routes the call to the appropriate extension.
Unified Messaging
Types of PBX
PBX systems are the most common telephone system type that medium- and large-size
organizations use. Several types of PBX systems are available:
Analog PBX Analog PBX systems send voice and signaling information, such
as the touch tones of dialed phone numbers, as actual analog sound. Analog PBX
systems never digitize the sound. To direct the call, the PBX and the phone company’s
CO listens for the signaling information.
Digital PBX Digital PBXs encode analog sound into a digital format. They typically
encode the voice using a standard industry audio codec, G.711. After digital PBXs encode
the sound, they send the digitized voice on a channel using circuit switching. The process
of circuit switching establishes an end-to-end open connection, and leaves the channel
open for the call’s duration and for the call’s users only. Some PBX manufacturers have
proprietary signaling methods for call setup, such as Avaya Definity G3si PBX.
IP PBX IP PBXs include a Network Interface Card (NIC) to provide voice over
regular network. The phone converts voice into digitized packets, which it then
transfers over the network. The network sends the voice packets via packet switching,
a technique that enables a single network channel to handle multiple calls. The IP PBX
also acts as a gateway between the internal packet-switched network and the external
circuit-switched networks that phone company’s use. In this situation, external phone
calls arrive at the IP PBX on the normal public phone lines, and the IP PBX converts the
phone call to packets sent on the internal IP-based network. An example of this is Cisco
Call Manager.
Hybrid PBX Hybrid PBXs provide both digital and IP PBX capabilities. This hybrid
approach enables a customer to run a mixture of digital and IP-based phones. Most
modern PBXs are in this hybrid category, such as SEN HiPath 4000.
VoIP Gateway Introduction
A VoIP gateway is a third-party hardware device or product that converts traditional
phone-system or circuit-switching protocols into data-networking or packet-switched
protocols. The VoIP gateway connects a telephone network with a data network.
Unified Messaging servers can connect only to packet-switched data networks. This means
that organizations with a traditional PBX must deploy a VoIP gateway to communicate
between the PBX and the Unified Messaging server.
Table 9-1 lists the types of telephony systems and explains when a VoIP gateway is required.
TABLE 9-1 VoIP Gateway Requirements for Telephone Systems
Traditional Centrex
IP Centrex
May not be required if supported
The Basics of Telephony
Key Telephone System
Required, some phone systems
are not supported
Analog or Digital PBX
IP or Hybrid PBX
May not be required is supported
A list of supported PBXs and IP gateways for Exchange 2010 Unified Messaging can be
found on Microsoft TechNet in Telephony Advisor for Exchange 2010 at http://technet
Unified Messaging Protocols
There are a number of voice-related, IP-based protocols. A Unified Messaging environment
with Exchange Server 2010 uses the following:
Session Initiation Protocol (SIP) SIP is a real-time signaling protocol that creates,
manipulates, and disconnects interactive communication sessions on an IP network.
The UM role uses SIP mapped over Transmission Control Protocol (TCP) and supports
TLS for secured SIP environments. SIP clients, such as IP/VoIP gateways and IP/PBXs,
can use TCP port 5060 or port 5061 (for Secure SIP) to connect to UM server roles. You
can find more information about the SIP protocol at
Real-time Transport Protocol (RTP) RTP is for voice transport between the
IP gateway and the Unified Messaging server. RTP provides high-quality, real-time,
streaming voice delivery. One of the issues with sending voice messages over an
IP network is that voice requires real-time transport with specific quality requirements
to ensure that the voice sounds normal. If the protocol uses large packets, listeners
must wait for the entire packet to arrive before they can respond. Any delay in packet
delivery can produce undesirable periods of midstream silence. Packet loss can cause
voice garbling. You can get more information about the RTP protocol at http://tools
Exchange Unified Messaging Architecture
The Unified Messaging server role includes connections to different components, such as the
Client Access or Mailbox server roles, and also to IP PBX or IP gateways, as shown in Figure 9-1.
Generally, the UM server role communicates to an IP PBX or to a PBX using an IP gateway
with the Voice over IP protocols (VoIP), Session Initiation Protocol (SIP), and Real-time
Transport Protocol (RTP).
The UM server role uses MAPI protocol to communicate with Client Access and Mailbox
server roles, and SMTP protocol to send voice mail messages to the destination mailbox via
Unified Messaging
Active Directory
Domain Controller
IP Gateway
Hub Transport
Access Server
FIGURE 9-1 Unified Messaging architecture
the Hub Transport server. For Outlook Voice Access the UM server role accesses the mailbox
using MAPI protocol to have full access to all items in the mailbox such as messages or
The Unified Messaging role no longer supports an inbound fax like Exchange 2007 UM.
However, UM retains fax configuration properties, and continues to be sensitive to fax tones
on calls that it answers and forwards these calls to a partner fax solution. The received fax
messages look essentially the same as those created by Exchange 2007 UM, and will appear
as a fax when the user is UM-enabled.
The communication to the other Exchange roles—namely the Hub Transport,
the Mailbox, and Client Access Server roles—uses MAPI connections to perform tasks
such as opening a mailbox for OVA or sending a voice mail message when the call
has ended.
Exchange Unified Messaging Architecture
Unified Messaging Services
The UM server role relies on several services that are required for UM to work correctly.
Table 9-2 shows the services that are added to the operating system when adding the
Exchange Server Unified Messaging role to a server.
TABLE 9-2 Exchange Services for Unified Messaging Role
Microsoft Exchange
Active Directory
This service reads information
from all Active Directory
partitions. The data is cached
and then used by Exchange
2010 servers to discover the
Active Directory site location
of all Exchange services in
the organization. It is also
responsible for updating the
site attribute of the Exchange
server object in Active
Runs on all Exchange servers
but Edge servers. Stopping
this service is the quickest way
to stop all Exchange services
because all other UM-related
services will also be stopped.
Microsoft Exchange
File Distribution
This service is responsible
for distributing files such as
the UM prompts to other
Exchange servers.
This service is required;
otherwise, the Unified
Messaging prompts are
not distributed to the other
Exchange UM servers.
Microsoft Exchange
Allows applications to call
the Exchange diagnostic
This service should be
started when you consider
implementing monitoring
tools such as System Center
Operations Manager.
Otherwise, you don’t need
to start it.
Microsoft Exchange
Service Host
This service provides a
host for several Exchange
The service should always be
in a running state; otherwise,
the Test-ServiceHealth cmdlet
will recognize it and report
a fail.
Microsoft Exchange
Speech Engine
Service (Only
Exchange 2010 RTM)
Provides speech processing
services for UM.
In SP1 this service was
replaced by Unified
Communications Managed
API 2.0 Core SDK (UCMA).
Unified Messaging
Microsoft Exchange
Unified Messaging
Enables Microsoft Exchange
Unified Messaging features.
This allows voice messages
to be stored in Microsoft
Exchange and gives users
telephone access to e-mail,
voice mail, calendar, contacts,
or an auto attendant.
When you stop this service,
the Unified Messaging server
won’t be able to accept and
process incoming calls. Before
stopping the service, you
should consider currently
active calls using the GetUMActiveCalls cmdlet.
Exchange 2010 SP1 no longer relies on the Microsoft Exchange Speech Engine
Service. It uses the Unified Communications Managed API (UCMA), which improves the
performance of the speech engine and provides Quality of Experience metrics.
Unified Messaging Folder Structure
Similar to the other Exchange roles, the UM server role also creates a folder structure in the
Exchange Installation folder. The folder structure is available in <Exchange_Install_Path>\
UnifiedMessaging and is described in Table 9-3.
TABLE 9-3 Unified Messaging Folder Structure
Badvoice mail
Includes voice mails that have been identified as bad or corrupt.
Includes grammar files for all languages installed on the UM server role.
Only used for special logging purposes by Microsoft CSS.
Includes the voice prompts for all languages installed on the
UM server role.
Used to store voice mails before they’re transferred to a Hub Transport
server role. If you see files in this folder, there is a problem sending them
to the Hub Transport.
Planning for Unified Messaging
Planning for the UM role requires you to consider the following UM-related areas beyond
server placement and configuration:
UM Server The server that handles voice access. UM servers can handle calls for
multiple dial plans and thus can be associated with multiple UM Servers.
UM Dial Plan Represents a set of telephony-enabled endpoints (extensions), sharing
a common numbering or naming plan, defined by the telephone network (such as PBX).
Planning for Unified Messaging
UM Hunt Group A hunt group associates an IP gateway with a dial plan, and may
have a pilot number to distinguish gateway associations with different dial plans.
UM Mailbox Represents the UM-enabled user. The mailbox has an extension
assigned to it in an associated dial plan. Users can have secondary extensions, and
these can be in different dial plans.
UM Mailbox Policy Associates the UM users with their dial plans and defines
additional policies such as PIN Policies for a user.
UM IP Gateway An IP gateway represents any SIP/RTP-capable peer server with
which UM is allowed to communicate. This includes VoIP gateways, IP PBXs, and Office
Communications Server.
UM Auto Attendant An auto attendant allows administrators to provide callers
with DTMF- and speech-enabled access to users, operators, and phone numbers.
Unified Messaging Servers
If you want to plan your Exchange 2010 Unified Messaging implementation, you need to
consider two important factors: How many UM servers do you need, and where do you
physically place your UM server roles? You can find additional information about UM server
role hardware planning in Chapter 13, “Hardware Planning for Exchange Server 2010.”
Planning Amount and Hardware for UM Servers
Planning for how many Unified Messaging servers you need for your environment is logically
the first question that needs to be answered before considering their configuration.
Planning the amount of UM servers depends mainly on the number of concurrent calls to
the server as well as how many Voicemail Previews a CPU has to produce. These assumptions
are based on an average voice mail of 50k and an average voice mail length of 30 seconds.
You can follow these guidelines for UM server planning:
From the processor power, assume that one voice mail per core per minute can
be produced. The UM role supports up to 12 cores, but because this is based on
a reasonable price and performance ratio, it might rise in the future.
Each language installed and supported on an UM server adds memory and CPU
overhead because it has to rebuild the language library of words every 24 hours.
Call answering rules do not have a measurable impact on processor power.
Every UM server can support as many as 200 concurrent calls maximum; the default
configuration is 100 concurrent calls.
If you don’t know your average concurrent callers, you can calculate that roughly
1 percent of your users produce concurrent calls at peak times. This means that
if you have 5,000 UM-enabled users accessing a single UM server, they produce
50 concurrent calls during peak hours.
Unified Messaging
You should plan to have at least two UM server roles available in your organization
to provide failover capabilities.
8 GB memory is the recommended memory configuration for a dedicated UM server.
More memory will not provide much benefit, even though UM will utilize it.
At Microsoft, three dedicated, centralized Exchange 2010 UM servers are currently
available that host more than 90,000 mailboxes. You can find additional hardware planning
recommendations in Chapter 13.
Voicemail Preview and CPU Scalability
Ankur Kothari
Senior Technical Product Manager, Exchange Server, Microsoft Corporation
calability of the messaging role is primarily bottlenecked at the CPU. The process
of taking an audio stream and determining a best-fit language model for the
words spoken is primarily a processor task. We estimate that a single CPU core
can handle one voice mail message per minute. An average voice mail message is
roughly 25 to 30 seconds, although this can vary by industry or geography. Planning
for CPU usage on this role is crucial to providing a consistent end-user experience.
UM Server Placement
If you have a small, single-site implementation of Exchange, you do not give much thought to
where you physically place the UM server role. However, if you have a global implementation
with several large branch offices located in different countries, you must ask yourself whether
you want to place a UM server role close to the branch office’s PBX or if you want to place the
UM server role in the location where the mailboxes are hosted. The subsequent discussion
uses the term PBX, meaning that the PBX can be connected to the UM role or already
includes an IP PBX.
Let’s use the Litware scenario and assume that you have mailboxes from your branch
offices in Brussels and Amsterdam hosted on the Mailbox server in Berlin. You also have local
PBXs available in Brussels and Amsterdam. Obviously you can place the UM server close to
the PBX or close to the Mailbox server role. The following considerations will help you to
make a valid decision for this situation:
Placing the UM server close to the PBX but far from the Mailbox server improves the
voice quality because the PBX to UM role is very close. The UM role might need a short
delay to open a mailbox and read the items, but the voice quality when the message is
played or sent is excellent. Having centralized UM servers and sending VoIP traffic over
an unreliable or high-latency WAN should be considered carefully. A delay in opening
Planning for Unified Messaging
messages could be acceptable for your users, but a delay in the voice traffic or bad
voice quality is not. On the other hand, having the UM server close to the PBX but far
from the Mailbox server also means that retrieving and playing personal greetings
may not work well. Because the event of “leaving a voice mail” is more of a one-way
conversation from the caller to the UM server, best practice is having the UM server
near the Mailbox server.
Placing the UM server close to the Mailbox role, but distant from the PBX might cause
voice issues if you do not have a Quality of Service (QoS) network that prioritizes VoIP
traffic over your WAN:
If you can guarantee or have sufficient network bandwidth available, it is best
practice to place the server close to the Mailbox server role.
If you cannot guarantee network quality between the PBX and UM server role, your
users might not be able to understand voice messages because of network latency
or outages, which might cause user confusion.
Security is another aspect worth considering. Most of the time voice mails are private,
and it is sometimes difficult or even unsupported on a lot of PBXs to have the RTP
protocol stream secured. This might be an easy target for eavesdropping.
You can also consider adding a multi-role server to the site where the PBX is located,
including the Mailbox, Client Access, Hub Transport, and UM roles to make sure all
traffic is local and users get the best voice quality possible. However, carefully consider
other implications, such as Domain Controller requirements, that you need to satisfy
before installing a multi-role Exchange server onsite.
The Microsoft recommended best practice is to place the UM server close to the
Mailbox, Hub Transport, and Client Access servers. An IP PBX/IP gateway roundtrip needs
to be less than 300 ms, which is higher latency than the RPC traffic between Exchange
servers can tolerate and still perform well.
UM Dial Plans
The UM dial plan is the basic Unified Messaging administrative unit and used for telephony
extension-numbering. The UM dial plan, plus the extension number, provides the unique
identifier for each UM-enabled user. The UM dial plan also controls the numbering scheme
and the outbound dialing plan.
The UM dial plan is an Active Directory container object that is a logical representation
of a Telephony dial plan that you configure on a PBX. The UM dial plan establishes a link
from an Exchange Server 2010 recipient’s telephone extension number in Active Directory
to a UM-enabled mailbox.
Before you can use Unified Messaging, your Exchange environment requires at least one
UM dial plan to be created, assigned to a UM server, and associated with a UM IP gateway.
Unified Messaging
When you configure UM dial plan settings, you have to define at least the extension
length. Additionally, you can configure other UM dial plan settings:
Access numbers for subscribers (OVA phone number) or your UM-enabled users dial to
access their mailbox via a phone.
Default greetings that is used when subscribers call into the UM server.
Dial codes for dialing external phone numbers and international numbers.
Features such as whether subscribers can transfer callers to other users and whom
callers can contact.
Time limits for calls, messages, and idle timeouts.
Default language for OVA and voice prompts.
The audio codec format for voice messages, such as MP3.
If you want to upgrade your existing Exchange 2007 UM environment
that is connected to OCS, you need to create new UM dial plans for Exchange 2010 UM to
make OCS UM-version aware. Until SP1, changing a user’s dial plan means de-provisioning
and re-provisioning a user from the UM system. SP1 changes that by enabling the Move
Request to update the UM dial plan automatically.
Exchange 2010 SP1 will include secondary UM dial plan support, which means that you can
assign two UM dial plans to your users, especially those who use two phones connected to
different gateways. For more information about this feature see the “Enabling Mailboxes for
Unified Messaging” section in this chapter.
UM IP Gateways
A UM IP gateway is a logical representation of a physical IP gateway hardware device that
translates between the circuit-switched telephone network and an IP or packet-switched
network. This represents either a VoIP gateway or an IP PBX.
The UM IP gateway contains one or more UM hunt groups and other UM IP
gateway-configuration settings, including the actual IP gateway. The combination of the
IP gateway object and a UM hunt group establishes a logical link between an IP gateway
hardware device and a UM dial plan.
Before an IP gateway can process calls, a UM IP gateway must be associated with at
least one UM dial plan.
You can create a UM IP gateway using the Exchange Management Shell (EMS) or
Exchange Management Console (EMC). When you create a new UM IP gateway, you enable
Planning for Unified Messaging
UM servers to connect to the VoIP gateway or IP PBX. However, you can enable or disable the
UM IP gateway. You can disable a UM IP gateway in two different modes:
Disable After Completing Calls Forces UM servers associated with this UM
IP gateway to stop handling any new calls.
Disable Immediately Forces all associated UM servers to drop existing calls for
this UM IP gateway.
UM Hunt Groups
A UM hunt group is a logical representation of an existing PBX or IP PBX hunt group. When
the hunt group’s pilot number receives a call, the PBX or IP PBX looks for the next available
extension number to deliver the call. When the call’s recipient does not answer an incoming
call, or the line is busy because the recipient is on another call, the PBX or IP PBX routes the
call to the UM server.
UM hunt groups act as a link between UM IP gateways and UM dial plans. Therefore,
you must associate a UM hunt group with at least one UM IP gateway and one UM dial plan.
UM hunt groups locate the PBX hunt group from which the incoming call was received. A
pilot number that is specified for a hunt group in the PBX also must be specified within the
UM hunt group. The pilot number enables the UM server to associate the call with the correct
UM dial plan so that it can route the call correctly.
When you create a new UM hunt group, you enable UM servers in the specific UM dial
plan to communicate with the UM IP gateway. You need to specify the UM dial plan and the
pilot identifier or pilot number that you want it to use with the new UM hunt group.
You can create UM hunt groups only if you have already created a UM IP gateway.
UM Mailbox Policies
You configure UM mailbox policies to standardize UM configuration settings, policies, or
security settings for UM-enabled users. When creating a UM dial plan, a respective UM
mailbox policy is created automatically, including default settings. Using UM mailbox policies,
you can configure the following settings:
Dial plan (required)
Maximum greeting length
Number of unsuccessful login attempts before password is reset
Minimum number of digits that a PIN requires
Number of days until user must create a new PIN
Number of previous passwords that are not allowed
Restrictions on in-country/region or international calling
Protected voice mail settings
Configuring inbound faxing to a fax partner solution
Unified Messaging
Each UM-enabled mailbox must link to one UM mailbox policy.
UM Auto Attendants
Using a UM auto attendant, you can create a voice-menu system that enables your callers
to navigate through voice menus to locate or transfer calls to your UM-enabled users or
departments. You can create and use your own voice prompts so that you’re able to fully
customize the UM auto attendant to your own needs.
The UM auto attendant uses a series of WAV files that callers hear instead of a human operator.
The callers can navigate the menu system, place calls, or locate users using DTMF or voice inputs.
You can join auto attendants together to form multi-level menus.
The UM auto attendant allows you to provide the following:
Corporate or informational greetings, such as business hours or directions to a location
Custom corporate menus that you can customize to have more than one level
A directory search function that enables callers to search the organization’s name directory
The ability for callers to connect to the telephone of—or leave a message
for—UM-enabled mailboxes
You are not limited in the number of UM auto attendants you can create, and each auto
attendant can support an unlimited number of extensions. However, you should design menu
systems for auto attendants carefully to ensure that the user has a positive experience. If
you design them incorrectly, users can become very frustrated if the time it takes to connect
correctly is lengthy or navigating the system is difficult. You should especially consider
creating additional UM auto attendants if you are operating in a multi-language environment
so that you can provide a dial-in number for each language.
When you create a UM auto attendant, you must provide the associated UM dial plan
and extension number(s) to access the UM auto attendant. After creating the UM auto
attendant, you can configure alternative greetings by specifying the WAV files to use.
You also can configure different settings for work and non-work hours and features
such as call transferring. You can create auto attendants in the EMC or by using the
New-UMAutoAttendant cmdlet in the EMS.
Call Answering Rules
Call Answering Rules or Personal Auto Attendants allow your users to create and customize
rules to enhance the experience that callers have when their calls are answered. For example,
the call answering rules can include features such as special greetings by contact or time of
the day. Using call answering rules, the caller can for example decide to:
Leave a voice message for the UM-enabled user.
Transfer to an alternate contact of the UM-enabled user.
Transfer to an alternate contact’s voice mail.
Planning for Unified Messaging
Transfer to other phone numbers that the UM-enabled user configures.
Use the Find-Me feature or locate the UM-enabled user via a supervised
Your UM-enabled users can configure up to eight call answering rules in OWA Options
or ECP, as shown in Figure 9-2.
FIGURE 9-2 Configuring Call Answering rules
Call answering rules consist of conditions, a greeting and menu, and actions. You can
configure call answering rules in Outlook Web App Options.
The following conditions for call answering rules are available:
If the caller is: calling from a phone number, this specific contact, or in
my contacts folder.
If it is during this period: working hours or nonworking hours to a
specific time defined.
Unified Messaging
If the user’s schedule shows a status of: free, tentative, busy, or away.
If you turn on automatic replies, such as when you turn on an automatic Out
of Office message.
Greeting and Menu
Greeting and Menu is the area where the caller can take specific actions that users predefine.
For example, after hearing a greeting that you previously recorded, you can provide a prompt
so that the caller can dial you at home.
When the users create their greetings, they have to take care of the entire caller
menu—the auto attendant will no longer prompt the caller.
Actions define the tasks that occur when callers choose specific menu selections. You can
select the following actions:
Find Me At The Following Numbers Defines a recording text, the number
key to press to transfer, and enables you to call two phone numbers for a
specific time.
Transfer The Call To Defines a recording text, the number key to press to transfer,
and either a phone number or a contact—or indicates that the call should transfer
directly to voice mail.
Leave A Voice Message Directly transfers the caller to voice mail.
Deploying Unified Messaging
Before you can use UM and OVA, you need to configure your UM server role.
Adding the UM Server Role
Before you can use UM, you need to install an Exchange server that includes the UM server
role. You can add the UM role to every server role except for the Edge Transport server role.
Depending on the size of your environment, you can decide whether you want to deploy
the UM role on a server that already hosts a role, or use a dedicated server to host the
UM server role. You can find more details how to deploy the UM server role in Chapter 15,
“Preparing for and Deploying Exchange Server 2010.”
Deploying Unified Messaging
Configuring UM Dial Plans
You need to create a UM dial plan to configure the number of extensions the UM server
will be accept. Each UM dial plan requires a specifically set URI type as well as VoIP security.
Table 9-4 lists the available URI types and when each one is used.
TABLE 9-4 URI Types Available in UM Dial Plans
Telephone Extension
Used if this UM dial plan is directly connected to an
IP gateway that cannot support SIP.
IP gateway uses SIP for signaling or if you are connecting to
OCS 2007 R2.
Your IP gateway delivers the URI in E.164 format.
Additionally, every UM dial plan can be configured for different VoIP security levels.
This basically dictates whether Mutual TLS and/or SRTP are required or disabled. An overview
of the available VoIP security levels is provided in Table 9-5.
TABLE 9-5 VoIP Security Levels Available in UM Dial Plans
UM server uses an unencrypted
communication over TCP port 5060.
UM server uses TLS to encrypt communication
over TCP port 5061. If you use this option
with OCS 2007, Office Communicator client
encryption level must be set to either Required or
Uses SIP encrypted communication over
TCP port 5061. If you use this option with
OCS 2007, Office Communicator client encryption
level must be set to either Rejected or Optional.
To create a UM dial plan, make sure you know the following information:
UM dial plan name
The number of digits needed for the extension number
URI type
VoIP security
Unified Messaging
If you are creating a UM dial plan for OCS, remember that you cannot use any
spaces or special characters—you can only use those that are supported by OCS 2007
Location Profiles.
To create a UM dial plan, you can use the EMC as shown in Figure 9-3, or you can use
the New-UMDialPlan cmdlet.
FIGURE 9-3 Creating a new UM dial plan
Configuring UM IP Gateways
You are required to create an IP gateway when you don’t use OCS 2007 R2 in your
environment and want to connect directly Exchange 2010 UM to your IP PBX or IP gateway.
If you use OCS 2007 R2, the task of creating an IP gateway per OCS Pool will be done by
the ExchUCUtil.ps1 script.
To create an UM IP gateway, you need the following information:
The name of the UM IP gateway
The IP address or FQDN of the IP gateway or IP PBX that you want to connect to
The UM dial plan the UM IP gateway will serve
To create a UM IP gateway, you can use the New-IPGateway cmdlet in the EMS or use the
EMC as shown in Figure 9-4.
Deploying Unified Messaging
FIGURE 9-4 Creating a new UM IP gateway
Configuring UM Hunt Groups
For every UM IP gateway you also need at least one UM hunt group. To create a UM hunt
group you need the following information:
Name of the UM hunt group
The pilot identifier for this UM hunt group
The UM dial plan the UM hunt group is part of
You can create the UM hunt group in the EMC, as shown in Figure 9-5, or you can use the
New-UMHuntGroup cmdlet.
FIGURE 9-5 Creating a new UM hunt group
Unified Messaging
Configuring UM Mailbox Policies
UM mailbox policies are required when you enable users for UM. They’re useful for applying
and standardizing UM configuration settings for UM-enabled users. You create UM mailbox
policies to apply a common set of policies or security settings to UM-enabled mailboxes and
UM servers. UM mailbox policies are used to configure the following settings:
General policies, such as allowing Voicemail Preview or configuring inbound faxes
Message text for system messages sent by the UM server
PIN policies
Dialing restrictions
Protected voice mail
You configure UM mailbox policies by using the EMC as shown in Figure 9-6, or you
can use the New-UMMailboxPolicy cmdlet.
FIGURE 9-6 Configuring UM mailbox policies
Configuring UM Settings
After you’ve configured the UM dial plan in Organization Configuration, you need to
assign the dial plan to the UM server role to enable it. In EMC you can perform this task
in Server Configuration-> Unified Messaging in the UM server’s properties, as shown in
Figure 9-7.
Deploying Unified Messaging
FIGURE 9-7 Configuring UM Settings in Server Configuration
On the UM server level, you can configure the following settings:
Associated Dial Plans Assigned This setting defines which dial plans the UM
server is serving.
Startup Mode Defines the startup mode of the UM server—namely TCP, TLS, or
Dual. If your UM server does not have a certificate installed, you should not switch to
TLS or dual startup mode. Select TLS-enabled mandatory encrypted communication
using SIP over TLS.
Maximum Concurrent Calls To prevent server overconsumption, you can
configure the maximum amount of concurrent calls this server can handle. The default
is 100 calls; the maximum is 200 calls.
Configuring Incoming Faxes
Exchange 2010 UM no longer supports inbound fax transcripts as it was available in the core
product with Exchange 2007, but the UM server role retains fax configuration properties and
forwards fax calls to a partner fax solution. This happens in the following way:
If a fax tone is detected, UM looks at the FaxServerURI configuration property on the
UM mailbox policy objects to determine if a partner fax solution is installed (and if so,
If a value is found for the property, UM will attempt to hand off the call in progress to
the partner fax solution. The partner fax solution will establish a fax media session with
the sender, create a fax message, and send it to the UM-enabled user’s mailbox.
Unified Messaging
Messages created by partner fax solutions will look essentially the same as those created
by Exchange 2007 UM, and will appear as a fax when the user is UM-enabled.
To have faxes forwarded to your partner fax solution correctly, you need to make sure that
the partner fax server is configured and you need to configure UM to make your fax partner
solution available to UM. When you configure the Exchange UM, make sure the following
areas are configured correctly:
Verify that UM dial plan is configured to allow users to receive faxes. You can do this
using the Set-UMDialPlan <UMDialPlan> -FaxEnabled $true cmdlet.
Configure the UM mailbox policy to forward faxes to the fax partner’s server. You
can do this using the Set-UMMailboxPolicy <UMMailboxPolicy> -AllowFax $true -FaxServerURI “sip:<faxserverFQDN>:5060;transport=tcp” cmdlet.
Make sure your UM-enabled mailbox can receive faxes.
To enable fax messages to be sent to a UM server from the partner fax server,
you also need to create a Send connector that is configured with the respective
authentication that the partner fax solution supports.
To find a suitable fax partner solution that meets your requirements, you can get an
overview of available fax solutions by reading the Fax Advisor for Exchange 2010 available at
International Considerations of Unified Messaging
In an international environment it is especially important to consider the foreign language
aspect of UM. In governmental agencies in particular it is common to speak and work not in a
common language, but in the local language, such as German.
If you add the UM server role, only one default language is added—English. Thus, you
need to define the additional languages required for your users.
Languages for Voicemail Preview
Ankur Kothari
Senior Technical Product Manager, Exchange Server, Microsoft Corporation
question I often receive is, “Why did you decide to ship X language and not Y
for Voicemail Preview?”
Our speech model for voice mail is highly tuned to each culture and language.
Dialects, vocal tones, grammar, background noise, and mumbling all challenge any
voice recognition technology. A language model can even have subtle challenges,
such as the method in which a phone number is recited in England is very different
than in the United States.
International Considerations of Unified Messaging
To address these challenges, we created a unique language model for each potential
language that we planned to ship. After getting each language model to an
acceptable level, we ran the results through a user panel to determine whether users
found the results usable or not. Different cultures, as you know, may interpret results
uniquely, and we wanted to determine whether our model met the bar. In the end,
we decided to ship seven languages/cultures for Voicemail Preview that exceeds
both our testing and the user experience. The four new languages in Exchange 2010
SP1 are Canadian English, Polish, Portuguese (Portugal), and Spanish (Spain).
Foreign Language Support
Unified Messaging provides language packs to satisfy international UM requirements. In multiplelanguage environments, you should install the applicable UM language packs because some UM
users prefer their voice prompts in a different language or because they receive e-mail messages
in multiple languages that they need to access using OVA. If you do not install the UM language
pack for a particular language, e-mail messages in that language will be illogical and incoherent
when relayed to the user. OVA uses the following language selection behavior in the release
version of Exchange 2010:
Try to find an exact match from the OWA language setting.
If no match is found, look for a language with the same parent language name.
If multiple languages with the same parent language name are installed, the
language that is last installed on the UM server wins.
If still no match, pick the latest language installed on the UM server.
Exchange 2010 SP1 changes the language selection behavior as follows:
Try to find an exact match from the OWA language setting.
If no exact match is found, fall back to a matching fallback language (en = en-US,
fr = fr-FR, es = es-ES, pt = pt-BR, and so on).
If no fallback language is installed, use the default language of the UM dial plan.
Several key components rely on UM language packs to enable users and callers to
interact effectively with Exchange Server 2010 UM in multiple languages. Each language pack
A Text-to-Speech (TTS) engine to read and convert messages when OVA users access
their inboxes.
The prerecorded prompts used to configure UM dial plans and auto attendants.
ASR support for speech-enabled UM dial plans and auto attendants.
To install a language pack, use /AddUMLanguagePack found in the Exchsrvr\Bin
directory of the Exchange Server installation. Once you install your language packs, you can
change the default language configured for each dial plan.
Unified Messaging
NOTE Users automatically use the default language if their configured language setting in
Outlook Web App is not available as a language pack. For example, if you install only the English
and German language packs, and the English language pack is the default on the dial plan,
a user with the French language configuration in Outlook Web App will hear English prompts.
In Exchange Server 2007, each language pack included the TTS engine but only supported
ASR for U.S. English. In Exchange Server 2010, all available language packs contain ASR
support. However, not all language packs support Voicemail Preview.
You can access and download all available UM language packs at http://technet
Operating UM in a Multi-language Environment
Providing UM to your users in a multi-language environment requires additional
considerations so that your users receive voice prompts for their local language. Consider
the following when planning a multi-language implementation:
Create one UM dial plan for every language you support. For example, if you set up
a UM server for Germany, you should configure a UM dial plan with its own subscriber
number that has German configured as default language in Language Settings.
You can only define a single text message in a UM mailbox policy. If you are in a
multi-language environment, you should consider either adding a text message for all
languages or using a common language only.
Minimize the number of languages to only the needed ones. Every language installed
requires time for grammar generation and language specific work. If you do install all
26 languages, this might never be finished.
You should consider a Subscriber Access number for every primary language that you
want to support so that your local users can access their mailboxes in their local language.
Changing Language for Voice Mail
Korneel Bullens
Team Coordinator Unified Communications, Wortell, Netherlands
ne of the questions I hear from my customers is “Why do I get my OVA
greeting in English while my colleague has a Dutch or English intro?” This is
a simple challenge. When your mailbox is created and you log on to Outlook or
OWA, you encounter a language selection process. The language you pick is the
language used on your voice mail. You can change this by opening Outlook Web
App and changing your regional settings back to your desired language.
International Considerations of Unified Messaging
Managing Unified Messaging
To manage the UM server role, you need to make sure you understand the tools available
and how to troubleshoot UM.
Enabling Mailboxes for Unified Messaging
For most people, enabling a mailbox for UM might seem straightforward, but it is not done
in the properties of the mailbox on the Mailbox Features tab, but using Enable Unified Messaging
in the Actions pane in the EMC as seen in Figure 9-8, or by using the Set-Mailbox cmdlet.
FIGURE 9-8 Enabling Unified Messaging for a mailbox
When you enable a user account for UM, you must specify a UM mailbox policy
and an extension, and you must assign a PIN or configure the system to generate the user’s
initial PIN. After enabling a user for UM, Exchange Server sends the user an e-mail message
indicating that the account is enabled. The message also contains the PIN. The user must use
touch tones to input a PIN when accessing the UM-enabled mailbox. Speech recognition is
not enabled for PIN input.
Since Exchange 2010 SP1 you can also add a mailbox to a secondary UM dial plan. This
is especially helpful if your user has multiple phones that are not part of the same UM dial
plan. For example, one of your users might be part of an OCS dial plan as well as an UM dial
plan that has a direct connection to an IP gateway using the URI type Telephony Extension.
Unified Messaging
You configure a secondary UM dial plan using the Set-Mailbox <Mailbox> -SecondaryAddress
<extension> -SecondaryDialPlan <UMDialPlan> cmdlet.
UM Reporting
For UM reports you required System Center Operations Manager 2007 and the Exchange
2010 Management Pack to be installed in Exchange 2010 RTM.
Exchange 2010 SP1 includes reports that allow you to verify UM quality metrics and see
details about the UM IP gateway’s specific voice mail calls performed. The call data records
for UM reporting are automatically stored after the call to the discovery metadata mailbox
found with the fixed name SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} for
90 days. This is enabled by default and cannot be changed. If you want to keep the records
for a longer period, you need to export them.
If you’re using OCS QmS (Quality of Experience Monitoring Server), the data is
automatically also available to OCS.
The UM reports are available in the EMC Toolbox, ECP, or EMS. The following UM tools are
Call Statistics Shows the calls made, the quality of the call, and so on. You also
can export a report and use another program such as Microsoft Excel to analyze it.
Alternatively, you also can use the Get-UMCallSummaryReport cmdlet in the EMS to
receive an aggregated view on calls received and made through your UM environment.
User Call Logs When users complain about the quality of voice mails, the
administrator can verify the UM logs to identify the reason for the issue. For example,
you will see a summary of the voice mails the user received and the respective IP
gateway of the voice mail, as shown in Figure 9-9.
FIGURE 9-9 Viewing User Call Logs
Managing Unified Messaging
Testing Unified Messaging Functionality
Testing the UM functionality is a bit trickier than testing other features such as message
routing because it involves multiple components in the testing process such as voice, mailbox
access, and so on. Only when testing this functionality end-to-end can you make sure it is
working as expected. Several tools are available for testing your UM functionality.
UM Troubleshooting Tool
The UM Troubleshooting Tool is available with Exchange 2010 SP1 as a separate download to
proactively test the voice mail functionality and identify any issues. The Troubleshooting Tool
is able to simulate a call from OCS or IP gateway to your UM server and verifies that the UM
communication is working as expected. It verifies that a call can be established, verifies that
the audio flow from the UM server works, and prepares quality metrics for recorded audio.
You can install the UM Troubleshooting Tool on a workstation or server. The
recommendation is to use an administrative workstation. It is available in x86 and x64
versions and requires the following prerequisites to be installed:
Windows PowerShell v2
.Net Framework 3.5 SP1
Unified Communications Managed API (UCMA) v3.5
The UM Troubleshooting Tool provides you with a shell similar to the EMS and allows you
to test UM connectivity with the Test-ExchangeUMCallFlow cmdlet, as shown in Figure 9-10.
FIGURE 9-10 Microsoft Exchange UM Troubleshooting Tool
If you want to use the UM Troubleshooting Tool to test your UM server, you need to
create the following:
A UM dial plan with Telephone Extension as the URI type and Unsecured as VoIP security
A UM IP gateway that points to the IP address of the workstation you installed the
UM Troubleshooting Tool on
A UM-enabled mailbox with an extension
Unified Messaging
After you create the prerequisites, run the Test-ExchangeUMCallFlow –Mode
GatewayEmulator –VoIPSecurity Unsecured –NextHopAddress <UMServer> -Diversion
<Extension> cmdlet to verify that the UM server is working correctly.
You can use this tool to run against Exchange 2010 UM SP1 servers only!
Exchange UM Test Phone
The Microsoft Exchange UM Test Phone is a software phone that you can use to connect to
your UM server and simulate specific IP gateway settings. It is based on the Exchange Speech
Engine and can be used to troubleshoot connectivity.
The UM Test Phone (ExchangeUMTestPhone.exe) is no longer available on the Exchange
2010 DVD, but you can get it from an Exchange 2007 DVD and use it against your Exchange
2010 UM server.
UM uses the Unified Communications Managed API 2.0 Core SDK (UCMA)
in Exchange 2010 SP1; the Exchange UM Test Phone cannot connect anymore to run
against SP1. You can only use it with Exchange 2010 RTM.
You can install the Exchange UM Test Phone on a workstation or server that includes
a microphone and speakers so you can verify that the speech is accurate and correct. Like the
Exchange 2007 installation files, it is available in x86 and x64 versions. The UM Test Phone is
shown in Figure 9-11.
FIGURE 9-11 Using the UM Test Phone
Managing Unified Messaging
Detailed information about how to test your UM server with the UM Test Phone can be
found at
Office Communication Server 2007
R2 Integration
Exchange Server 2010 UM provides OCS 2007 R2 with the voice mail feature, and OCS 2007
R2 can make presence information and instant messaging features available to your OWA
users. You can also configure an automatic switchboard for your OCS 2007 R2 voice-enabled
users using an UM auto attendant.
UM can also utilize an existing IP PBX that is configured with OCS 2007 R2—you do not
need additional hardware to connect UM to your PBX if OCS 2007 R2 is installed already. Thus
any PBX configuration can be managed from the OCS 2007 R2 side, and does not need to be
configured again in Exchange 2010.
OCS 2007 R2 also provides other features that integrate into UM:
Instant messaging The OCS 2007 R2 client provides instant messaging (IM)
functionality that the OCS hosts. The solution provides IM features, such as group IM,
and extends the internal IM infrastructure to external IM providers. You can implement
IM directly into OWA.
Presence information OCS 2007 R2 tracks presence information for all OCS users
and provides this information to the OCS 2007 R2 client and other applications, such as
Outlook 2007. You can implement presence information directly into OWA.
Web conferencing OCS 2007 R2 can host on-premise conferences, which you can
schedule or reschedule, and they can include IM, audio, video, application sharing,
slide presentations, and other forms of data collaboration.
Audio conferencing Users can join OCS 2007-based audio conferences using any
desk or mobile phone. When connecting to an audio conference using a Web browser,
users can provide a telephone number that the audio-conferencing services calls.
VoIP telephony Enterprise Voice enables OCS 2007 R2 users to place calls from
their computers by clicking an Outlook or Communicator contact. Users receive calls
simultaneously on all their registered user endpoints, which may be a VoIP phone,
a mobile phone, or an OCS 2007 R2 client. The OCS 2007 R2 Attendant is an integrated
call-management client application that enables a user, such as a receptionist, to
manage many conversations simultaneously.
Response Group service This service enables administrators to create and
configure one or more small response groups for routing and queuing incoming
phone calls to one or more designated agents. Typical scenarios include an internal
help desk or customer-service desks.
Unified Messaging
OCS 2007 R2 Integration: Extension Numbers
Korneel Bullens
Team Coordinator Unified Communications, Wortell, Netherlands
ne of the things I am always asked about is when deploying OCS Enterprise
Voice as PBX replacement; the users still require an extension number. When
you configure the UM dial plan for OCS connectivity, you select SIP dial plan as the
URI type and you still need to configure the number of digits in extension numbers
for the UM dial plan. Many of the administrators I talk to would not expect to be
asked for an extension number in an OCS- and UM-only scenario.
When you think about it, it’s quite logical. You need a unique identifier when
someone calls his voice mail from outside the company, and needs to select his own
voice mail box. This is when the extension number comes into the game. You are
free to assign your own extension numbers, just make sure when you create the UM
dial plan, the amount of digits suits your needs. If you deploy 120 users for UM, use
only three digits. Fewer digits mean fewer numbers to remember for your users.
Integrating OCS 2007 R2 in Exchange 2010 Architecture
Exchange 2010 UM completes the offering of OCS 2007 R2 with a voice mail solution based
on messaging. This requires a tight integration between OCS 2007 R2 and Exchange 2010
UM. Together with the integration of IM in OWA, OCS 2007 R2 can be described as being
fully connected to Exchange Server 2010, as shown in Figure 9-12.
The UM role communicates to the OCS Mediation server using the OCS Pool Name
and thus contacts the OCS Front-End server. All signaling communication (SIP) and the voice
stream (RTP) pass the OCS Front-End server.
When Office Communicator clients access their voice mail mailbox, they also do not
directly contact the Exchange UM server role. Their communication is also handled by the
OCS Front-End server.
For more details about the communication between OCS 2007 R2 and UM, you
can access the Office Communications Server 2007 R2 Workload Architecture Poster at
Office Communication Server 2007 R2 Integration
SIP (Session Initiating
Protocol) for signaling
RTP (Real-time Transport
Protocol) for real-time
audio and video data
G711 or
OCS 2007 R2
Mediation Server
Exchange UM Server
UM Dial Plan =
OCS Location Profile
Exchange CAS
Server Role
OCS 2007
R2 Server
Instant Messaging
in OWA
FIGURE 9-12 OCS 2007 R2 integration in Exchange 2010 architecture
Deploying UM and OCS 2007 R2 Integration
If you want to implement OCS 2007 R2 or later into your Exchange 2010 UM, your
environment should consider the following requirements:
One or more OCS 2007 R2 Front-End servers.
At least one OCS 2007 R2 Mediation server connected to your PBX or phone system.
UM server roles require a digital certificate that is enabled for UM service on
that server.
Unified Messaging
One or two phone numbers per OCS Location Profile—at least one for Subscriber
Access and optionally one for an UM auto attendant. Particularly if you want to
connect multiple office locations, you should consider at least a subscriber access
number that is in the local phone range, but you can use a single UM auto attendant
for the company.
Follow these steps to install OCS 2007 R2 integration for UM:
Create a UM dial plan for each of your available OCS Location Profiles:
a. The dial plan name should, for example, include information about Exchange UM
and only include characters supported by an OCS 2007 R2 Location Profile (such as
no spaces).
b. URI Type = SipName
VoIP security = Secured or SIPSecured (OCS 2007 does not support unsecured
VoIP security!)
Make sure that your Office Communicator client encryption level reflects the
VoIP security setting. If you configure VoIP Security as SIP Secured, you need to set
it either to Rejected or Optional. If you use Secured as VoIP Security level, it must be
either Required or Optional.
Configure your UM dial plan(s) with the correct OCS Location Profile Subscriber Access
phone number.
Associate the UM server with the UM dial plans and make sure Startup Mode is Dual.
If Startup Mode is changed, you need to restart the Microsoft Exchange UM service.
Run the ExchUCUtil.ps1 script found in the <Exchange_Install_path>\Scripts folder. The
script will perform the following tasks:
a. Create one UM IP gateway for each OCS 2007 Enterprise Pool
b. Create a UM hunt group for each UM IP gateway with their respective Pilot
Grant OCS 2007 servers permission to read Exchange UM objects in Active
Use the Set-UMIPGateway cmdlet to configure the Port parameter of every created
IP gateway to port 5061. You also use this cmdlet to disable outbound calling for all but
one UM IP gateway. This is usually the gateway that is likely to handle the most traffic.
Run the Get-UMDialPlan –Id <DialPlanName> |fl PhoneContext cmdlet in EMS and
remember the PhoneContext property—you’ll need to create an OCS Location Profile
with that exact name.
Create and configure required UM auto attendant(s). Assign them the correct UM dial
plan and the access phone number from the OCS Location Profile.
Office Communication Server 2007 R2 Integration
On your OCS 2007 R2 Front-End server, create an OCS Location Profile in OCS 2007 R2
for the UM dial plan you created that matches the PhoneContext name.
Run the OcsUMUtil.exe tool found in the C:\Progam Files\Common Files\Microsoft
Office Communication Server 2007 R2 folder. The tool will verify that OCS Location
Profile and UM dial plan names match and allow you to create contacts for your
Subscriber Access as well as auto-attendant access numbers.
Unified Messaging Transitioning and Extension Dialing
Gary A. Cooper
Senior Systems Architect, Horizons Consulting, Inc., United States
ithin our organization, we had been utilizing Exchange Server 2007
UM in conjunction with Office Communication Server 2007 R2. This solution
worked well, but we required the new features in Exchange Server 2010
UM—specifically RMS-protected Voicemail and Voicemail Preview. When we
originally configured Exchange Server 2007 UM, we did not have enough Direct
Inward Dial (DID) numbers for each mailbox that was UM-enabled, so we instead
configured Exchange Server 2007 UM to use the auto attendant to answer all inbound
calls and then to prompt the caller to select the appropriate person to contact. This
worked well until we introduced Exchange Server 2010 and DID numbers.
To implement Exchange Server 2010, we had to create a new dial plan for OCS to
route properly to the new UM server. This now forced each user to have two new
EUM address entries after we moved their mailboxes to Exchange Server 2010 and
migrated their UM to Exchange Server 2010 UM (by removing their old UM settings
and re-provisioning them).
EUM: [email protected];phone-context=<NewDialPlanName>
In testing, what we found was that if a call came into OCS for a mailbox we had
already moved to Exchange 2010 UM, the main number would be answered by the
auto attendant in Exchange Server 2007 UM; then, when the older UM server tried
to route the caller to the Exchange 2010 UM server, it would error and tell the caller
“The call has failed, please press ‘0’ (zero) for the operator or dial someone by name
or extension to reach them directly.” If the caller tried to dial by name or extension
number to mailboxes still on Exchange Server 2007 UM, it worked without issue.
Behind the scenes, Exchange UM couldn’t find the migrated mailbox and would
route the call back to OCS 2007 R2, which would route it back to Exchange UM,
and so on, and eventually the call failed and the caller was dropped.
Unified Messaging
In working with Product Support Services, we determined that Exchange 2007 was
still looking for the proxy address for its dial plan in the following format:
We determined that when the caller entered the extension (such as - 204),
Exchange Server 2007 UM would search for the user in the current dial plan (the
dial plan associated with the auto attendant that answered the call)—in this case
the Exchange 2007 Sip_Name dial plan. It did this search by constructing the EUM
address (204; phone-context=<Exchange 2007 Dial plan Name>.< Exchange 2007
Dial plan GUID>) and then searching all Active Directory users to check whether any
user had this stamped in their proxy addresses. However, the migrated mailbox that
has been moved to Exchange 2010 UM-has been provisioned on the new Exchange
2010 Sip_Name dial plan, so it no longer has the Exchange 2007 proxy address, and
so the user object is not located.
The solution we ended up implementing was to add the legacy EUM proxy address
back to the mailbox object, thus enabling extension dialing from both Exchange
2007 and Exchange 2010 UM services.
Deploying Instant Messaging for OWA
A new feature in Exchange 2010 is the integration of Instant Messaging (IM) into Outlook
Web App, so your OWA users can see who is online and directly chat with the users without
the requirement of installing Office Communicator on their client computer.
IM integration for OWA does not require a UM server role to be installed in your
environment; it just requires OCS 2007 R2 to be available. For that reason the feature also
does not require an Exchange E-CAL like UM does.
To deploy this functionality, you need to install the OCS 2007 R2 Web Service Provider on
all Client Access servers, enable IM on the Client Access server, and configure the OCS 2007
R2 Server to be able to access the Client Access server.
For IM integration you need the following:
The Firewall configuration between the OCS 2007 R2 and Client Access server needs
to allow the following TCP ports: 5061 (SIP), 5075, 5076, and 5077.
The Client Access server requires a digital certificate that includes the FQDN or Client
Access server array name as Subject Name and is from the same CA as the certificate
of the OCS server. Certificates from different CAs—even if the CAs are trusted—might
cause problems.
Office Communication Server 2007 R2 Integration
You must perform the following steps on every Client Access Server role where users
access OWA and want to use IM:
Download the Microsoft Office Communications Server 2007 R2 Web Service Provider
at and run CWAOWASSPMain.msi to
extract the package:
a. Run vcredist_x64.exe to install Microsoft Visual C++ 2008 Redistributable.
b. Run Ucmaredist.msi to install the OCS 2007 R2 Unified Communication Managed
API 2.0 Core Redistributable.
Run CWAOWASSP.msi to install the OCS 2007 R2 Web Service Provider.
Download and install the API 2.0 Core update for Windows Server 2008 R2 with the
file name UcmaRedist.msp at
Identify the Client Access server’s certificate subject name and thumbprint using the
Get-ExchangeCertificate |fl cmdlet.
Configure the OWA Virtual Directory of the Client Access server to enable IM
by running the Get-OwaVirtualDirectory –Server <CAS-server> | SetOWAVirtualDirectory –InstantMessagingServerName <OCS-server> - InstantM
essagingCertificateThumbprint <thumbprint> -InstantMessagingEnabled $true –
InstantMessagingType OCS cmdlet, as shown in Figure 9-13.
<- Required for OCS Configuration (Authorized Host)
<- Required for Exchange CAS Configuration (see below)
FIGURE 9-13 Enabling IM on Client Access server
In Exchange 2010 RTM this task required modifying web.config file located in
the <Exchange_Install>\ClientAccess\Owa folder. If you have not installed Exchange
2010 SP1 yet, please follow the instructions to configure the web.config file at http://
Restart World Wide Web Publishing Service to apply the changes. Remember,
restarting the service will disconnect all active users.
Unified Messaging
After you have configured the Client Access Server role, you need to perform the following
steps on your OCS 2007 R2 Server:
In the Office Server 2007 R2 Management Console, on your OCS 2007 R2 pool, open
Front-End properties.
On the Host Authorization tab, click Add Authorized Host and configure the Client
Access Server or the Client Access Server namespace. In Settings, select Throttle As
Server and Treat As Authenticated, as shown in Figure 9-14.
FIGURE 9-14 Adding an authorized host in OCS 2007 R2
The Server name must be exactly the same as the Subject name of the
certificate you have configured on your Client Access server(s).
For the settings to take effect immediately, you need to restart Office
Communication Server Front-End service. Be aware that this will disconnect any
active users.
After you’ve configured your OCS 2007 R2 and Client Access Server role, your users
should see their presence information and should be able to chat with their contacts
using OWA as shown in Figure 9-15.
Office Communication Server 2007 R2 Integration
Change your
presence information
Active chats
See presence
information about your
FIGURE 9-15 Instant Messaging integration in OWA
Additional Resources
Quick Start Guide for Outlook Voice Access 2010:
Telephony Advisor for Exchange 2010:
RFC 3261 - SIP: Session Initiation Protocol:
RFC 3550 - RTP: A Transport Protocol for Real-Time Applications:
Fax Advisor for Exchange 2010:
Client Language Support for Unified Messaging:
Testing a Unified Messaging Server with the Unified Messaging Test Phone: http://
Office Communications Server 2007 R2 Workload Architecture Poster: http://www
Managing Outlook Web App and Office Communications Server 2007 Integration:
Unified Messaging
Federated Delegation
Introduction to Federated Delegation in Exchange Server 2010 445
Fundamentals and Components of Federated Delegation
Federation Scenarios
Troubleshooting Federated Delegation
he days when a user worked exclusively with internal recipients are long behind
us. Today information workers collaborate with a multitude of external recipients
including customers, vendors, and partners. As part of this collaboration, users
frequently need to share their availability (free/busy) information, calendar details, and
even their contacts with external recipients. In addition, this ability is commonly required
in cross-premises scenarios where a portion of the organization is hosted externally with
the rest hosted in-house.
To provide a solution for sharing information externally in a secure fashion,
an underlying trust framework is provided by federation in Exchange Server 2010.
Federated delegation (formerly known as federated sharing) then uses the federation
framework to allow for the secure sharing of availability, calendar details, and contacts
with external recipients.
In this chapter, we will discuss the technology and best practices surrounding
federated delegation, beginning with an introduction and overview of the technologies
and concepts, followed by a discussion on managing federation and delegation in your
environment. Then we’ll go over various federation scenarios, and finally wrap things up
with troubleshooting federation and federated delegation.
Introduction to Federated Delegation
in Exchange Server 2010
Before jumping into managing federated delegation and a discussion of the various
scenarios, let’s start out with an overview of federation, its challenges, and its
implementation in Exchange Server 2010.
Overview of Federation and Federated Delegation
Federated delegation in Exchange Server 2010—and the underlying federation infrastructure
with the Microsoft Federation Gateway—is an innovative means of securely sharing
information with external recipients with minimal management overhead compared with
traditional federation technologies. A common request is for end users to determine the
availability of users in other organizations when planning meetings, short of calling them on
the phone and asking them what times work for them.
Federation Overview
For Star Trek fans, federation may have a different meaning, but for the purposes of this
discussion federation is used in the context of federated identity. Federated identity means
a user’s authentication and authorization process across multiple IT systems (or Exchange
organizations, in our case). It can also refer to the assembling of a user’s identity from
disparate identity management systems, but for the purposes of this discussion we are
concerned with authentication and authorization.
Federation is a claims-based means of providing secure Web-based authentication and
authorization across organizations and platforms without needing to replicate or reproduce
the user’s identity or attributes (referred to as “claims,” such as e-mail address, UPN, display
name, and so on) in another directory or other information silo. This means that a user can
perform single sign-on (SSO) across organizational boundaries without the need for directory
or GAL synchronization, or learning another set of credentials, or needing to have the other
organization store and manage replicated credentials or directory objects. A user’s identity,
e-mail address, and other requested attributes are asserted as claims in tokens, which are
presented to an application to verify the user and the user’s attributes. Microsoft’s federation
implementation, Active Directory Federation Services (AD FS), was first introduced in
Windows Server 2003 R2 and is based on the industry standard WS-Federation specification,
which is part of the WS-* Web Services Architecture.
In a typical deployment, federation was enabled between organizations through each
organization standing up a federation infrastructure and then establishing a secure federation
trust between them. These federation trusts are conceptually similar to Active Directory forest
trusts in that a trust was established between the organizations to allow one organization
to trust authentication tokens issued by the other organization. In reality, a federation trust
is Web-based and is enabled through the sharing of public keys between the organizations,
unlike Active Directory trusts. In addition, because it is Web-based, a federation trust requires
only port 443 communication between the components.
Because these federation trusts are at the organizational level, every organization must
create a trust with every other organization. This means that to establish trusts with multiple
organizations, (n*(n–1)) trusts are required, where n represents the number of organizations
involved. This is illustrated in a configuration involving four organizations in Figure 10-1.
Federated Delegation
FIGURE 10-1 Multiple federation trusts in a standard federation deployment
As you can see, the standard federation deployment shown in Figure 10-1 means that the
configuration and management of a large number of trusts can quickly become unwieldy
as more organizations are involved, requiring you to share your public keys with each
organization you have a trust with, and maintain their public keys in your organization.
Role of the Microsoft Federation Gateway
To simplify this management challenge, Exchange Server 2010 uses the Microsoft Federation
Gateway (MFG) as a trust broker. The Microsoft Federation Gateway is an identity backbone
that runs in the cloud, acting as a hub for federation activity between (in this case) Exchange
Server 2010 organizations. This means that you only need to create one federation trust with
the Microsoft Federation Gateway rather than with each organization you want to establish
a relationship with. The MFG will be discussed in more detail in the next section of this
chapter, but an example of the federation trusts with the MFG are shown in Figure 10-2 for
the same four organizations depicted in Figure 10-1. To establish a trust with the Microsoft
Federation Gateway service, your organization must obtain an X.509 certificate from a
third-party certificate authority (CA) as well as verify their ownership of the domain they
are federating by publishing an application identifier (appID) in a TXT resource record in the
DNS zone for that domain. The certificate and DNS requirements for the federation trust are
discussed in more detail in the “Federation Trust” section of this chapter.
It is important to point out that the Microsoft Federation Gateway acts as a broker
service (intermediary) only; no credentials or passwords are stored there and no Windows
Live accounts are necessary for its use. Its only function is to facilitate the federation
trust to enable organizations to share information securely without needing to establish
individual trusts between each other.
Introduction to Federated Delegation in Exchange Server 2010
Microsoft Federation
FIGURE 10-2 Microsoft Federation Gateway as trust broker
After you have created a single federation trust with the MFG for your organization, you
simply configure an organization relationship with another organization to enable you to start
sharing information securely; you don’t need to exchange any certificates or metadata with
the other organization. We will discuss federation trusts and organization relationships in more
detail in the “Fundamentals and Components of Federated Delegation” section of this chapter.
Fundamentals and Components
of Federated Delegation
The primary components of federation delegation are the federation trust, organization
relationships, and sharing policies.
Federation Trust
The following prerequisites are necessary for creating and managing the federation trust:
The domain used for establishing a federation trust must be resolvable from the
Internet. This means that the domain must be resolvable via DNS from the Internet
and that the domain is registered with a domain registrar. Best practice is to use your
primary SMTP domain (for example, rather than your internal Active
Federated Delegation
Directory namespace, which may not be resolvable from the Internet (for example,
For cross-premises scenarios, where an organization hosts some mailboxes on
site and hosts others in the Exchange Online service, it is recommended to use
a sub-domain of exchangedelegation.<your primary SMTP domain> to avoid
namespace conflicts with the Exchange Online tenant namespace. Your primary
SMTP domain should then be added as an additional URI to your federated
organization identifier using the Add-FederatedDomain cmdlet.
You require a valid X.509 SSL certificate issued by a Certification Authority (CA) trusted
by Windows Live to be able to configure a trust with the MFG. The CAs trusted by
Windows Live (and, by extension, the MFG) are listed in the “Certificate Requirements
for Federation Trust” section of this chapter, along with more details on the subject
name requirements.
After the federation trust is created, you must provide proof of ownership for the
domain specified by creating a TXT resource record in your external DNS. This TXT
record contains the application identifier (AppID) provided in the output when the
federation trust is created with either the New Federation Trust Wizard or the
New-FederationTrust cmdlet.
Certificate Requirements for Federation Trust
The certificate used for the federation trust must meet the following requirements:
The certificate must be issued by a certification authority trusted by the MFG.
You can obtain the most current list of trusted root Certification Authorities
at, but the following CAs
are presently trusted:
Digicert Global Root CA
Digicert High Assurance EV Root CA CA (2048)
Entrust Secure Server CA
Go Daddy Secure Certification Authority
The certificate must have a subject key identifier field. The X.509 certificates issued
by the majority of commercial CAs have this field already.
Certificates using Cryptography Next Generation (CNG) cryptographic service
providers (CSPs) aren’t supported for federation; the certificate must use
a CryptoAPI CSP. A CryptoAPI provider is used when you create your certificate
request using the Exchange Server 2010 New Certificate Wizard.
The certificate must use the RSA signature algorithm.
Fundamentals and Components of Federated Delegation
The private key for the certificate must be exportable. This is configured automatically
when you create the certificate request using the New Certificate Wizard in the EMC
or the New-ExchangeCertificate cmdlet.
The certificate must be current and valid; an expired or revoked certificate cannot
be used.
The certificate must include the enhanced key usage (EKU) type Client Authentication
(; this usage type is used for proving your identity to a remote
computer. The Client Authentication usage type is included by default when you use
the New Exchange Certificate Wizard in the EMC or the New-ExchangeCertificate
cmdlet to generate the certificate request.
The certificate used for the federation trust does not have any subject name
or subject alternative name requirements; the subject name can be the server’s host name
or the domain name—or any other name can be specified. When the trust is established,
Exchange Server 2010 distributes the certificate to all other Exchange Server 2010 Client
Access and Hub Transport servers in the organization automatically, as discussed in the
Certificate Distribution section of this chapter.
Creating the Federation Trust
You create the federation trust by exchanging the X.509 certificate for your organization
with the MFG, and retrieving the X.509 certificate and federation metadata from the MFG.
These tasks are performed for you when you create the federation trust with the Exchange
Server 2010 Exchange Management Console (EMC) or Exchange Management Shell (EMS).
In the EMC, you create the federation trust by selecting the Organization Configuration
node and then clicking New Federation Trust on the Actions pane as shown in Figure 10-3.
FIGURE 10-3 Creating a federation trust in the EMC
In the resultant New Federation Trust Wizard (shown in Figure 10-4), you select the
certificate used for the trust and create the trust by clicking New.
Federated Delegation
FIGURE 10-4 The New Federation Trust Wizard
Creating a federation trust is a one-time configuration; you can only have one
federation trust per Exchange Server 2010 organization. After the trust is created, the New
Federation Trust option is no longer available in the EMC.
You can also create the federation trust using the New-FederationTrust cmdlet in the EMS.
The parameters required for the cmdlet are -Name and –Thumbprint. -Thumbprint is the
thumbprint of the certificate being used for the federation trust; to get a list of the certificates
available and their thumbprints, use the following cmdlet:
Get-ExchangeCertificate | where {$_.IsSelfSigned -eq $false} | fl
After you obtain the thumbprint, the federation trust is created with the
New-FederationTrust cmdlet. An example of this cmdlet for Contoso with a certificate
with a thumbprint of AC00F35CBA8359953F4126E0984B5CCAFA2F4F17 is as follows:
New-FederationTrust -Name "Contoso-MFG Trust" -Thumbprint
After the federation trust has been successfully created, an AppID is provided in the output
of the New Federation Trust Wizard (or the output of the New-FederationTrust cmdlet, if you
created your federation trust using the EMS). This AppID is used in configuring your accepted
Fundamentals and Components of Federated Delegation
domains for federation, as explained in the “Managing Federation” section of this chapter.
You can also view the AppID for your organization in the Manage Federation Wizard in the
EMC or by using the Get-FederationTrust cmdlet.
An example of obtaining the AppID for Contoso using the Get-FederationTrust cmdlet is
as follows:
Get-FederationTrust | fl name, appl*
The output of this cmdlet should be similar to the following:
: Contoso-MFG Trust
ApplicationIdentifier : 000000004001A66A
When you create the federation trust with either the New-FederationTrust cmdlet or the New
Federation Trust Wizard, the task also copies the certificate used to all CA and Hub servers in
the same Active Directory site. The Cert Distribution Service, which is part of the MS Exchange
Service Host service, then distributes the certificate to remote sites as follows:
The Cert Distribution Service on CA and Hub servers in remote Active Directory sites
monitors Active Directory for changes on the certificates and tries to retrieve the new
certificate immediately on any change. The service detects new certificates through reading
the certificate thumbprint stored in Active Directory.
The Cert Distribution Service will first attempt to retrieve the new certificate
from a CA or Hub server within the same Active Directory site.
If the certificate is not available within the same site, the service will attempt
to retrieve the new certificate from CA or Hub servers in adjacent sites, such
as any that are one hop away. It will try the sites in the order of least Active
Directory cost.
If retrieving the new certificate from an adjacent site fails, an error is logged
and the service attempts to retrieve the certificate again in one hour.
Managing Federation
After you have created your federation trust, you must perform some management and
configuration steps.
After you have created your federation trust, you must provide proof of ownership for the
domain specified during the creation of the trust, as well as any other accepted domains
you will be using with federation; we will discuss configuring additional accepted domains
Federated Delegation
for federation in the “Configuring Domains for Federation” section of this chapter. Providing
proof of ownership is accomplished by creating a TXT resource record in your external DNS
containing the AppID provided when the federation trust was created. This TXT record is
created in the DNS zone for each accepted domain using federation. The following is an
example of this text record for Fabrikam: IN TXT AppID=000000004001A66A
You specify which authoritative accepted domains in your Exchange organization are
configured for federation through the use of the federated organization identifier; domains
are added to the federated organization identifier, then proof of ownership is established
through creating a TXT record for that domain as outlined in the “Configuring DNS for Proof
of Ownership” section of this chapter. A user must be configured with an e-mail address
defined in the organization identifier for the MFG to recognize that user and allow that user
to use any of the federated delegation features.
The first domain used for federation is set using the Set-FederatedOrganizationIdentifier
cmdlet with the –AccountNamespace parameter; this is the only federated domain that
is configured in the MFG. The URIs (Uniform Resource Identifiers) for additional domains
are configured in the federated organization identifier through the use of the Manage
Federation Wizard in the EMC or by using the EMS. The following cmdlet adds the domain as a federated domain:
It is not necessary to configure additional URIs if all users have a primary or
secondary SMTP address for the domain defined in the -AccountNamespace parameter of
your federated organization identifier. Whether the domain is their primary SMTP address
is unimportant.
Adding an accepted domain using the Manage Federation Wizard in the EMC is shown
in Figure 10-5.
To determine which domains in your organization are federated, you can use the cmdlet
Get-FederatedOrganizationIdentifier; this cmdlet outputs all of the federated domains defined
in the federated organization identifier. You can also view the federated domains by using the
Manage Federation Wizard in the EMC.
Fundamentals and Components of Federated Delegation
FIGURE 10-5 Adding accepted domains for federation using the Manage Federation Wizard
The X.509 certificate used for the federation trust is specified during the creation of the
trust and automatically distributed to all Client Access and Hub Transport servers in your
organization, as outlined in the Certificate Distribution section of this chapter. If you need to
replace the federation trust certificate, you accomplish this by installing the new certificate on
an Exchange Server 2010 Client Access or Hub Transport server (or some other computer with
the Exchange Server 2010 management tools installed) and then configuring the federation
trust from that computer to designate it as the Next Certificate. Exchange Server 2010 then
automatically distributes the certificate to all Exchange Server 2010 Client Access and Hub
Transport servers; when this distribution has completed, the federation trust is switched to the
new certificate by defining it as the Current Certificate.
You can manage the certificates used for federation with the Set-FederationTrust cmdlet;
the –Thumbprint parameter configures the specified certificate as the next certificate,
as shown in this example:
Set-FederationTrust -Identity MyFederationTrust -Thumbprint
After the next certificate has been designated, it is automatically distributed to all
Exchange Server 2010 Client Access and Hub Transport servers. You can use the
Test-FederationTrustCertificate cmdlet or the Manage Federation Wizard to check the
distribution status of the certificate. The distribution process is described in detail in the
“Certificate Distribution” section of this chapter.
After the distribution of the next certificate has been verified, you can set it as the current
certificate, as shown here:
Set-FederationTrust –PublishFederationCertificate
Federated Delegation
Alternatively, you can manage the federation certificates using the Manage Federation
Wizard as shown in Figure 10-6.
FIGURE 10-6 The Manage Federation Wizard
Organization Relationships
After you have created and configured a federation trust, you can establish organization
relationships with other organizations (assuming that they have established a federation trust
of their own).
Organization relationships provide the means to share availability (free/busy) information
between organizations. When you create an organization relationship with an external
organization, users in that external organization can access availability information for
your users. For your users to access availability information from the external organization,
however, an organization relationship must be configured on their side as well.
You can configure an organization relationship using either the EMC or the EMS.
Having a federation trust in place is a prerequisite to successfully creating an organization
relationship. In the EMC, you start the New Organization Relationship Wizard by selecting
Organization Configuration on the navigation pane and then clicking New Organization
Relationship on the actions pane, as shown in Figure 10-7.
Fundamentals and Components of Federated Delegation
FIGURE 10-7 Starting the New Organization Relationship Wizard
To create an organization relationship to share availability information, on the Introduction
page of the wizard you define a name for the relationship, define the free/busy data access
level, and specify a security distribution group containing the internal members whose free
busy data will be accessible via the relationship, as shown in Figure 10-8. The free/busy data
access level can be set to three levels:
No Free/Busy Access (used when organization relationship is established for
federated delivery only)
Free/Busy Access With Time Only
Free/Busy Access With Time, Plus Subject And Location
FIGURE 10-8 Introduction page of the New Organization Relationship Wizard
Details, attachments, and attendees are not made accessible via the organization
relationship; to view that level of information, the user must create a Sharing Invitation
to the user in the other organization. The level of detail that can be shared via a sharing
invitation is determined by the Sharing Policy assigned to the user; Sharing Policies and
sharing invitations are discussed in more detail in the “Sharing Policies” and “Calendar
and Contacts Sharing” sections of this chapter.
Federated Delegation
On the External Organization page of the wizard, you can specify a federated domain of
the external organization and have the configuration information automatically discovered
via the MFG as shown in Figure 10-9. Alternately, you can manually enter the configuration
information in the bottom half of the screen.
FIGURE 10-9 External Organization page of the New Organization Relationship Wizard
Via the EMS, you can create an organization relationship by automatically discovering the
configuration as shown in the following example:
Get-FederationInformation -DomainName | New-OrganizationRelationship -Name
"Contoso" -FreeBusyAccessEnabled $true -FreeBusyAccessLevel LimitedDetails
An important point to note is that for Get-FederationInformation to work, DNS records
must be correctly configured so that Autodiscover is resolvable to an external-facing CA
server. For example, for the preceding cmdlet a CNAME record must be in place to resolve to an Exchange Server 2010 Client Access server that is accessible
from the Internet.
Alternatively, the following example shows how you can configure an organization
relationship with Contoso by specifying the configuration information manually if
Autodiscover is unsuccessful:
New-OrganizationRelationship -Name "Contoso" -Domainnames "","northamerica"," europe.contoso" -FreeBusyAccessEnabled $true -FreeBusyAccessLevel
LimitedDetails -TargetAutodiscoverEpr "
autodiscover.svc/wssecurity" -TargetApplicationUri ""
Fundamentals and Components of Federated Delegation
In most cases, it is recommended to resolve any Autodiscover issues, if possible, and then
create the organization relationship by retrieving the configuration information from the
Microsoft Federation Gateway automatically.
Sharing Policies
Organization relationships allow for sharing of availability information between organizations.
Sharing polices enable your users to share calendar and/or contact information on
a person-to-person basis with external users in other federated Exchange Server 2010
organizations. This is independent of organization relationships, and requires the
participation and consent of both users (the user in your organization and the external user
the information is being shared with).
Having a federation trust in place is a prerequisite to using sharing policies; although
sharing policies can be defined without a federation trust, they have no effect without
the trust. A sharing policy is comprised of the external domains to share information with,
the level of detail allowed to be shared, and the mailboxes the policy is applied to.
You can identify various levels of detail to share with the specified domains:
Calendar sharing with free/busy information only
Calendar sharing with free/busy information, plus subject and location
Calendar sharing with free/busy information plus subject, location, and body
Contacts sharing
Calendar sharing with free/busy information only, Contacts sharing
Calendar sharing with free/busy information, plus subject and location;
Contacts sharing
Calendar sharing with free/busy information plus subject, location, and body;
Contacts sharing
Figure 10-10 shows a policy being created for Contoso users to share complete Calendar
information as well as Contacts with users.
After you define the sharing policy, you assign it to the appropriate users. If a user is not
assigned a specific sharing policy, the default sharing policy applies to that user. One sharing
policy must always be designated as the default policy.
Users can create a sharing invitation in Outlook 2010 or OWA and define the level of
detail to share with the external user up to the level allowed by the sharing policy assigned
to them. For example, if the sharing policy assigned allows “Calendar sharing with free/busy
information, plus subject and location” with, the user can either share only her
availability, or share limited details with users from; she will not be able to share
the body of calendar entries or Contacts with users.
Federated Delegation
FIGURE 10-10 The New Sharing Policy Wizard
Only one sharing policy can be assigned to any one user, although a sharing policy can
include numerous domain and action pairings. In addition, a sharing policy can include the
* domain definition, which means that the action defined applies to all domains, unless a
more specific domain and action pairing is defined in the same policy.
To disallow any person-to-person sharing for particular users, simply disable
the sharing policy assigned to those users. Disabling the default sharing policy disallows
person-to-person for all users except those assigned other policies that are still enabled.
Interaction of Permissions, Organization Relationships,
and Sharing Policies
Because federated delegation is a new topic for most Exchange Server 2010 administrators,
let’s examine the relationship between Calendar permissions (the Access Control List, or ACL,
on the user’s default Calendar), sharing policies, and organization relationships.
An important point to keep in mind is that any organization relationships in place honor
the permissions defined for the default entry in your calendar’s permissions dialog. That is,
if the default entry is changed from the standard Free/Busy time setting to None, neither
external nor internal users will see your free/busy information.
Fundamentals and Components of Federated Delegation
To enable free/busy information sharing with another organization at the organization
level, both organizations must have a valid federation trust in place. In addition, the
organization that is sharing free/busy information must have an organization relationship
configured for the SMTP domain of the organization free/busy information is to be shared
with. In a case where recipients for your organization are defined in the GAL of the external
organization, you need to work with the administrators of that organization to make sure
that those recipients have the correct target address set because Exchange uses the target
address of an external recipient to find the organizational relationship. To provide for
two-way sharing, both organizations must have applicable organization relationships in place.
This offers sharing of free/busy information only, providing that information which is available
via the availability service.
In contrast to an organization relationship, where access is determined by the permissions
defined for the default entry in your calendar’s permissions dialog, when you share your
calendar with an external user via a sharing invitation, a unique entry for that user is added
to the ACL for your Calendar, as shown in Figure 10-11. As this behavior implies, access is still
ultimately controlled by the permissions set on the calendar.
FIGURE 10-11 Calendar Permissions dialog box
However, the primary difference between organization relationships and sharing policies
is that whereas organization policies provide access to the Availability service between
organizations, sharing policies provide the ability for end users to share their Calendars
and/or Contacts in a person-person relationship. The level of detail they can share is
determined by the sharing policy applied to their mailboxes. When sharing of a Calendar or
Contacts folder has been set up, that folder is synchronized to a folder in the mailbox of the
person you shared the Calendar or Contacts with.
Federated Delegation
Federation Scenarios
Let’s see how the basic principles of federation and federated delegation and the various
components and fundamentals of federated delegation in Exchange Server 2010 all
fit together. We’ll do this by covering the various federation scenarios in an Exchange
Server 2010 environment, and the advantages and drawbacks to each of them.
The common component in all of these scenarios is the creation of a federation trust, as
discussed in the “Federation Trust” section of this chapter; for the purposes of this discussion,
we will assume that the trust is in place and configured for all accepted domains in t