Exchange 2013 Sample Architecture Part 2: High-level Architectural Design Document


This section provides an introduction into the key elements of the Exchange 2013 Architectural solution. It provides high-level solution overview and is suitable for all technical project stakeholders. The excerpts of the final design document are listed under this post and the full High Level Design document can be downloaded here: RoadChimp Sample Architectural Doc (ADOC) v1.1

1. Messaging Infrastructure function

The Messaging Infrastructure serves the primary function of providing electronic mail (E-mail) functionality to Chimp Corporation. The messaging infrastructure supports E-mail access from network connected computers and workstations as well as mobile devices. E-mail is a mission critical application for Chimp Corp and it serves as an invaluable communications tool that increases efficiencies and productivity, both internally to an organization, and externally to a variety of audiences. As a result, it is of paramount importance for the Chimp Corp to maintain a robust infrastructure that will meet present and future messaging needs.

Key requirements of the messaging infrastructure are as follows:

  • Accommodate service availability requirements
  • Satisfy archiving requirements
  • Satisfy growth requirements
  • Provide required business continuity and disaster recovery capabilities

1.A. About IT Services (ITS)

The IT Services Organization is responsible for managing the IT environment for the Chimp Corp as well as ensuring adherence to published standards and operational compliance targets throughout the enterprise.

1.B. Service Level Agreement (SLA)

The Email infrastructure is considered mission critical and, therefore, has an SLA requirement of 99.99% availability.
The full SLA for the messaging environment can be found in the document <Link to SharePoint: Messaging SLA> 

1.C.  Locations

The messaging infrastructure is hosted from two separate datacenters being at:

  • Datacenter A (DCA)
    Chimp Center Prime
    1 Cyber Road,
    Big City
  • Datacenter B (DCB)
    Chimp Center Omega
    10 Jungle Way,
    Banana Town

The messaging infrastructure is supported by the IT Services Support Organization located at:

  • Chimp Corp Headquarters
    Chimp Center Prime
    Bldg 22, 1 Cyber Road,
    Big City

1.D.     E-mail User Classifications

The primary users of the messaging system are Chimp Corp employees. The user base is divided in two groups as follows:

  •     Exec: users performing Senior or Critical corporate functions
  •     Normal: the rest of the user population

2. Existing Platform

This section of the Asset document provides an overview of the present state of the asset, as well as a chronological view of changes based on organizational or technological factors.

2.A.     Existing Exchange 2003 design

A third-party consulting company performed the initial implementation of the messaging environment in 2000. The messaging platform was Microsoft Exchange 2003 and Windows 2003 Active Directory. The diagram below provides a representation of the existing design blueprint.

Exchange 2003 Environment

Fig. 1 Existing Messaging Environment

A single unified Active Directory Domain namespace was implemented in a Single Domain, single Forest design.

2.B. Change History

Over the years the Chimp Corp messaging environment has undergone various changes to maintain service level and improve functionality. The timeline below shows the changes over time.

Chimpcorp Timeline
Fig. 2 Chimp Corp Messaging Infrastructure Timeline

2.B.1   Initial Implementation

The Exchange 2003 messaging infrastructure was implemented by IT Services in 2005 and the entire user base was successfully migrated over to Exchange 2003 by September 2005.

2.B.2   Linux Virtual Appliances deployed for Message Hygiene

A decision was made by IT to deploy a Message Hygiene environment for the company in Windows 2013.

 This change was scheduled as maintenance and was executed early 2009.

2.B.3   Additional Datacenter Site (Omega)

In order to improve infrastructure availability and to support additional growth of the corporate environment, a second datacenter site, codenamed Omega was commissioned and fully completed by March of 2009.

2.B.4   Two Exchange Mailbox Clusters (A/P) deployed in the Omega Datacenter Site

To improve the availability of e-mail for users and also to meet plans for storage and user growth, two additional Exchange Mailbox Servers were deployed in Datacenter Omega (DCB).

2.B.5   Third-party archiving solution

A third party archiving solution was deployed by IT Services in 2010 as part of efforts to mitigate growth of the Exchange Information Stores, based on recommendations from their primary technology vendor. The archiving solution incorporates a process known as e-mail stubbing to replace messages in the Exchange Information Stores with XML headers.

2.B.6   Acquisition by Chimp Corp

After being acquired by Chimp Corp in September 2011, immediate plans were laid out to perform a technology refresh across the entire IT infrastructure.

2.B.7   Active Directory 2008 R2 Upgrade

The Windows Active Directory Domain was updated to version 2008 R2 in native mode in anticipation of impending upgrades to the Messaging infrastructure. The replacement Domain Controllers were implemented as Virtual Machines hosted in the Enterprise Virtual Server environment running VMWare vSphere 5. This change was completed in March 2012.

2.C. Existing Hardware Configuration

The current hardware used in the messaging platform consists of the following elements:

2.C.1   Servers

Existing server systems comprising the messaging environment include:

    • 12 x HP DL 380 G4 servers at DCA with between 2 – 4 GB of RAM
    • 10 x HP DL 380 G4 servers at DCB with between 2 – 4 GB of RAM

2.C.2   Storage characteristics

Exchange storage used for databases, backups, transaction logs and public folders have been provisioned on:

    • 2 TB of FC/SAN attached storage provisioned for 5 Exchange Storage Groups and 21 Databases and Transaction Logs
    • 2 TB ISCSI/SAN attached storage Archiving

2.D. Network Infrastructure

The Chimp Corp email infrastructure network has two main physical locations at the DCA and DCB datacenter sites. These are currently connected via the Chimp Corp LAN/WAN. The core switches interconnecting all hardware are Cisco 6500 Series Enterprise class switches.

2.E.  Present Software Configuration

Software and licenses presently in use include:

  • Microsoft Windows 2003 Standard
  • Microsoft Windows 2003 Enterprise
  • Microsoft Exchange 2003 Standard
  • Microsoft Exchange 2003 Enterprise
  • Third Party SMTP Appliances
  • A Stub-based third-party Email Archiving Tool

3. Messaging Infrastructure Requirements

The design requirements for the Exchange 2013 messaging environment have been obtained from the project goals and objectives, as listed in the Project Charter for the E13MAIL Project.

The primary objective for the E13MAIL Project is to ensure continued reliability and efficient delivery of messaging services to users and applications connecting to Chimp Corp from a variety of locations. Stated design goals are to increase performance, stability and align the operational capabilities of the messaging environment with Industry Best Practices.

The requirements/objectives for the messaging infrastructure are:

  • Redundant messaging solution deployed across 2 datacenter locations; DCA and DCB.
  • Capable of Audit and Compliance requirements
  • High Availability (99.99%)
  • Monitoring of services and components
  • Accurate configuration management for ongoing support
  • Adherence to Industry Best Practices for optimal support by vendors and service delivery organizations
  • Reliable Disaster-Recoverable backups, with object level recovery options
  • Message Archiving functionality with a maximum retention period of 7 years

4. Design Components

The primary messaging solution is to deploy new Exchange 2013 environment that spans Chimp Corp’s physical data center locations and extends into Microsoft’s Office 365 cloud to take advantage of the latest user productivity and collaboration features of Microsoft Office 2013.

The main goals for this solution are:

  • Minimize end-user impact: Minimizing the end-user impact is a key goal for Chimp Corp. Significant effort must be made to ensure that the transition of all e-mail related services are seamless to the end-user.
  • Reliable delivery of services: The messaging environment is a mission critical component of Chimp Corps IT infrastructure and adheres to strict Change Management practices. The solution must be able to integrate with existing Operational and Change processes.
  • Longevity of solution: The new messaging solution must endure beyond the initial implementation as it evolves into a production state. This requires the necessary attention to ensuring that operational knowledge is transferred to IT Services technical teams such that they can maintain uptime requirements.

The individual design components were subjected to a stringent evaluation process that included the following design criteria:

  •     Costs of Ownership
  •     Technological engineering quality
  •     Scalability
  •     Fault Tolerance / Reliability
  •     Industry best practices
  •     Supportability
  •     Ease of administration
  •     Compatibility with existing systems
  •     Reliability
  •     Vendor specifications

4.A. Hardware technology

IT Services researched the server solutions from a number of hardware vendors and made a final decision in favor of HP, Brocade and Cisco vendor equipment.

4.A.1   Server hardware

The server platform used is the eighth generation (G8) HP Blade 400-series server. This is an Intel based server system. The CPUS’s in these systems are standardized to Intel Xeon E5-2640 processors; these are hex-core processors with a 2.5 GHz speed. The servers are equipped with 128 GB of memory to accommodate their specific functions. The blade servers are provisioned in HP Blade C 7000 class enclosures.

4.A.2   Storage hardware

To accommodate the storage requirements two storage arrays are implemented. The primary array is an HP EVA 6400 class Storage Area Network. This array is equipped with 25TB of RAW storage and is used for on-line, active data. The secondary array is an HP P2000 G3 MSA class storage area network. This array is equipped with 15TB of RAW storage and is used for secondary storage like archives, backups etc.

4.A.3   Interconnect technology

HP’s Virtual Connect technology is used to accommodate network connectivity to both the storage network and the data networks. The virtual connect technology acts as a virtual patch panel between uplink ports to the core switching infrastructure and the blade modules. The virtual connect backplane will connect the network connections into a Cisco based core network. The storage area network is interconnected via a Brocade switch fabric.

4.A.4   Server Operating Systems technology

The majority of the messaging infrastructure components will be deployed onto the Microsoft Windows Server 2012 Operating System platform, licensed to the Enterprise version of the operating system. For systems that do not support Windows Server 2012, Windows Server 2008/R2 will utilized.

4.A.5   Messaging platform technology

A pristine Microsoft Exchange Server 2013 will be implemented in a hybrid configuration, featuring two major components:

  • On-premise Exchange 2013: The on-premise environment to support core business functions that cannot be moved to the cloud due to compliance reasons.
  • Office 365: All non-compliance restricted users will be migrated onto the Office 365 cloud.

The hybrid deployment will feature full interoperability between on-premise and cloud-based users, featuring single sign-on, sharing of calendar Free/busy information and a single unified OWA login address.

4.A.6   Back-end Database technology

Microsoft SQL Server 2012 was selected as the database platform to support all non-Exchange application requirements. The selection criterion for this product was partly dictated by the usage of technologies that depend on the SQL server back-end. As part of simplification and unification, it is preferred to keep all back-end databases in the messaging infrastructure on the same database platform.

4.A.7   Systems Management Solution

Due to the diversity of software applications and hardware in this infrastructure, a mix of management tools and products are used to manage all aspects of the messaging infrastructure. Major components are listed below:

(a)    Server hardware management: Vendor provided HP System Insight Manager hardware tools are used in combination with Microsoft System Center Operations Manager (SCOM) to provide hardware-level monitoring and alerting.

(b)    Server event management: Microsoft Systems Center Operations Manager (SCOM) 2012 is used for server event consolidation, management and alerting.

(c)     Server Applications management: Server software management comprises of systems patch management and server provisioning.

    • Systems patch management: Windows Systems Update Server (WSUS) integrated into Systems Center Configurations Manager (SCCM) provides patch management of all Windows Server Operating Systems in the messaging environment.
    • Server Provisioning: Server Provisioning for both bare metal and virtual server deployments are managed via the HP rapid deployment pack (HP/RDP)

4.A.8   Message Security and Protection technology

The following Security and Protection products have been selected:

  • Server Virus protection: McAfee Antivirus has been selected to protect the server operating system.
  • Message hygiene: Microsoft Exchange Online Protection (EOP) will be used for message hygiene and protection.
  • Security events auditing: Microsoft SCOM has been selected to capture information such as security auditing and alerting events that are generated from the server platforms.

4.B. Functional Blueprint

The blueprint below illustrates the desired messaging infrastructure:

Exchange 2013 Design

Figure 3 Chimp Corp Functional Messaging Design 


In the next section we will cover more detailed aspects of the Exchange 2013 design, as well as Server Virtualization Considerations for deploying Exchange 2013.

For the next part of this post, please click here.

Exchange 2013 Brief – Hybrid Deployments

Executive Overview

The cloud offers consumers more options for deploying their applications and is attractive from the perspective of predictable costs, reliability and scalability. However, not every component of an Organization’s environment may be fully suited for the cloud due to a variety of reasons including confidentiality and compliance. With the increasing trend of organizations to move parts of IT onto the cloud and retain core aspects of their business within their datacenters, it becomes important for us to understand how Exchange 2013 interoperates between on-premises and cloud. Exchange 2013 is designed from the ground up to support coexistence with the cloud. From both the administrator and end-user’s perspective, Exchange 2013 and Office 365 provide a seamless and feature rich experience. We will explore some of these features in this post.

Notable Features

  • Secure mail routing
  • Mail routing with the same domain space
  • Unified GAL and Free/Busy sharing
  • Centralized Egress of Messages
  • Unified OWA login
  • Centralized Management
  • Mailbox Migrations
  • Cloud-based Message Archiving


  • Architecture Components: A hybrid Exchange 2013 environment comprises of the following components.
    • Exchange servers: You may have a combination of Exchange 2013, Exchange 2010 or earlier Exchange Servers and roles deployed on-premises. You will need a minimum of one Exchange 2013 Client Access and one Exchange 2013 Mailbox Server if you deploy Exchange 2013 on-premises in your organization.
    • Microsoft Office 365: This is Microsoft’s feature-rich cloud based service that includes cloud-based email, instant messaging and online conferencing, Office Web Apps including Word, Excel, Powerpoint and OneNote and Email Archiving. You will need the Midsize Business and Enterprise Plan (E3) in order to configure Active Directory Synchronization with your on-premises environment. You will also need to configure an Exchange Online organization to enable hybrid deployments.
    • Exchange Online Protection (EOP): EOP is included in all Office 365 Enterprise tenant subscriptions. EOP enables secure message delivery between cloud and on-premises Exchange Organizations and can also be configured to manage message routing between the Internet and your on-premises Exchange Organization.
    • Hybrid Configuration wizard: The Hybrid Configuration wizard is used to manage the hybrid configuration through the Exchange Administrative Center (EAC). The Hybrid Configuration Wizard first performs prerequisite and topology checks, tests account credentials between on-premise and Exchange Online organizations and then subsequently performs the necessary configuration changes to create and enable the hybrid deployment, this includes adding the HybridConfiguration object in the on-premise Active Directory environment.
    • Microsoft Federation Gateway: On-premises Exchange Organizations must configure a federation trust with the Microsoft Federation Gateway before they can enable a hybrid configuration with an Exchange Online organization. The Microsoft Federation Gateway acts as a trust broker between the on-premises Exchange and the Online Exchange organizations and federation trusts can be configured manually or via the Hybrid Configuration Wizard. A Federation Trust is necessary for your on-line and on-premise users to be able to share free/busy information.
    • Active Directory Synchronization: AD synchronization enables a unified GAL across Online and on-premises users in your Exchange deployment. AD Sync feature requires you to download and install the tool on a separate server (Physical or Virtual) in your on-premises environment. Note that the default limit of 20,000 objects that can be replicated between on-premises Active Directory and the online organization can be increased by contacting the Microsoft Online Services team.
    • Active Directory Federation Services (Optional): the AD FS server implementation will enable users in your organization to use their existing network credentials for logging on to the on-premises and Exchange Online organizations using “Single Sign-on”. This is facilitated by configuring trusts between the on-premises Active Directory Forest and the Microsoft Online ID.
    • Certificates: To support secure communications between the on-premises and Online environments, Microsoft recommends that you purchase a Subject Alternative Name (SAN) SSL certificate that can be used to secure access to the following services:
      • Primary shared SMTP domain: This is your primary email domain and needs to be installed on local Client Access and Mailbox Servers. ie.
      • Autodiscover: The autodiscover services supports the configuration of remote clients (Outlook and Exchange Active-sync), is installed on your CAS servers and should be provisioned according to the external Autodiscover FQDN of your Exchange 2013 CAS server. ie. autodiscover.
      • Transport: This is installed on your Exchange 2010 SP3 Edge Transport Servers and matches the external FQDN of your edge transport servers. ie.
      • AD FS (optional): A certificate is required to establish trust between web clients and federation server proxies and to sign and decrypt security tokens.
      • Exchange Federation: A self-signed certificate is required to establish a secure connection between the on-premises Exchange 2013 servers and the Microsoft Federation Gateway.
      • Client Access: An SSL certificate is required for use by clients such as OWA and Exchange ActiveSync and Outlook Anywhere. ie.
  • Message Transport: Messages between the on-premises and online organizations are encrypted, authenticated and transferred via Transport Layer Security (TLS). Depending on how you choose to configure your hybrid environment, messages can flow either one of the following ways:
    • Centralized Mail Transport: All Internet-bound email is delivered via the on-premises Exchange Organization. The Exchange on-premises organization is responsible for message transport and relays all Internet messages from the Exchange Online organization. This configuration is preferable if your organization has compliance or regulatory requirements and must monitor a single point of egress for all messages outside of your organization. Ensure that you provision sufficient bandwidth between the on-premises and online environments to process all outbound messages.
    • Online-centric Transport: All Internet-bound email in the Organization is delivered via the Exchange Online organization. In this case, all external outbound messages from the on-premises Exchange Organization are relayed to servers in the Exchange Online organization. This is preferable if you wish to use Microsoft’s Exchange Archiving and Exchange Online Protection (EOP) solutions, as it supports the most efficient flow of messaging traffic.
    • Independent message routing: All Internet-bound email from recipients in the Exchange Online organization are delivered directly to the Internet, taking an independent path from your on-premises Exchange 2013 Organization.
    • Edge Routing: On-premises endpoint for Exchange and Exchange Online organizations must be an Exchange 2013 CAS Server, or Exchange 2010 SP3 Edge Transport Server. Communications between Exchange Online and older versions of Exchange, SMTP hosts or appliances  are not supported.
  • Client Access: In Exchange 2013 client access is supported from Outlook via RPC/HTTP and Outlook Web App. Clients connecting to the on-premises Client Access server are redirected to either the on-premises Exchange 2013 Mailbox Server or provided with a link to logon to the Exchange Online organization.

Common Administrative Tasks

  1. Set up an Office 365 account: Via the Office 365 online portal here.
  2. Enabling a Hybrid Deployment: Use the Hybrid Deployment Wizard in the EAC.
  3. Configure  or modify the Hybrid Deployment Options: Via the Hybrid Deployment Wizard in the EAC or Powershell
    Set-HybridConfiguration -Features OnlineArchive,MailTips,OWARedirection,FreeBusy,MessageTracking
  4. Verify the configuration was successful: Via PowerShell
  5. Sharing Free/Busy information: Steps on how to configure Federation Trusts
  6. Configuring Active Directory Synchronization: Steps to download the AD Synchronization tool from the Office 365 portal.

Top PowerShell Commands/Tools:

– Set|Update|Get-HybridConfiguration

Click here to read more briefs on Exchange 2013.


PowerShell Command Reference for Hybrid Configuration
Technet: Article on the Hybrid Configuration Wizard
Technet: Article on Hybrid Certificate Requirements
Technet: Article on configuring message routing
Labs on AD Synchronization

Exchange 2013 Configuration Guides

A warm Ook and hello from your banana loving primate friend! I’ve decided to put up a list of configuration guides for Exchange 2013 in an easy to access part of this blog. The configuration guides will help you to perform (hopefully) some tasks that you may find useful. I will post links to various guides on this page.

1. Exchange 2013 in Windows Azure

2. Configuring a Hybrid Exchange 2013 Deployment


I hope to get more posts out there. Thanks for all your comments and likes!

Road Chimp saying Ook!



Exchange 2013 Architecture Series – Part 3: Mailbox and Storage Design

Hello all, in this third section on Exchange 2013 Architecture, we will look into the Exchange storage subsystem and build around some best practices on Exchange 2013 design.

Exchange Storage Types

Before you start provisioning your Exchange Server 2013 environment, it’s useful to think about the different types of storage that a healthy Exchange environment uses. Each storage classification has its own unique performance requirements, and a well-architected Exchange storage architecture will be designed in order to support these needs.

  • Operating System and Page File Volumes: At the most fundamental level, all Exchange Servers run on top of an Operating System. In addition to storing the OS Kernel, the Operating System volume manages all I/O operations on the Exchange Server, as well as memory allocation and disk management.
  • Exchange Binaries: These volumes contain the actual application files that Exchange needs to run and follows the path: <Drive:>Program FilesMicrosoftExchange ServerV15. Microsoft requires at least 30GB of free space on the drive you wish to install the Exchange binaries on.
  • Exchange Database Volumes: These volumes store the actual Exchange Database files, which follow the format ‘.edb’. Enhancements in the Exchange Server database engine have resulted in reductions in disk resource requirements. However, database volumes should still be optimized for high performance and commonly use RAID striped volumes with parity to support high IOPS.
  • Exchange Database Log Volumes: Exchange 2013 uses a relational database technology that utilizes transaction logs to record changes to the Exchange Databases. The database log volumes are write intensive in nature.
  • Exchange Transport Database Volumes: Changes to how Exchange 2013 manages mailflow have resulted in the creation of several new features known as Shadow Redundancy and Safety Net. Read my previous post for more information on these new features. For Shadow Redundancy, the transport server makes a redundant copy of any messages it receives before it acknowledges successfully receiving the message back to the sending server. The Safety Net feature is an updated version of the Transport Dumpster and retains copies of retained messages in a database for a default of 2 days, via the SafetyNetHoldTime parameter. You should design your storage to accommodate two full days of additional e-mails within a high-availability boundary.
  • Backup/Restore Volumes: With database replication and resiliency features of Exchange now providing fault tolerance and high availability, backup and restore services are less crucial. However, they must be considered in the event of restoring historical or archived data. Most organizations consider less expensive storage types such as WORM (Write one, read many)

Storage hardware technologies

Exchange 2013 supports the following storage hardware technologies:

  • Serial ATA (SATA): SATA disks are cost effective, high capacity storage options that come in a variety of form factors. Microsoft recommends that you do not store your Exchange databases across a spanned volume comprising of multiple SATA drives.
  • Serial-attached SCSI: SCSI is a mature disk access technology that supports higher performance than SATA, but at a higher cost.
  • Fibre Channel (FC): Fibre Channel (note the spelling) support high performance and more complex configuration options such as connectivity to a SAN at a higher cost. FC disks are typically used in a collection of disks known as an Array and support the high-speed transmission of data (up to 16Gbps and 3200 MBps) and potentially require expensive fibre-channel infrastructure (known as switch-fabric) supporting single-mode or multi-mode fiber cables. The advantages of Fibre-channel are that the disks can be colocated a significant distance away from the actual servers (hundreds of meters up to Kilometers) without experiencing any loss in performance, which means that an organization can consolidate the disks used by numerous applications into one part of the datacenter and configure them optimally with high-redundancy features. This is the basic justification for a SAN.
  • Solid-state Drive (SSD): SSD drives use flash-type memory to store data and have a number of advantages of conventional SATA and SCSI based disk technologies which still employ rotary mechanical operations to access and write data on spinning platters. SSD drives are a relatively newer technology and currently support lower disk capacities but feature very high performance, boasting low disk access times (0.1ms compared to SCSI 4-12ms times). Due to their high cost, it is common for organizations to build servers with a combination of disk types, using SSD for Operating System partitions as well as volumes that benefit from write-heavy access, such as transaction log volumes for relational database systems.

Logical Storage Architectures

Exchange 2013 has changed how it addresses storage architecture from the ground up. Since the Extensible Storage Engine was rewritten via managed code and optimized for multiple threading, the storage design for Exchange has had to change as well to keep up. Microsoft provides the following recommendations with respect to the following storage architectures:

  • Direct/Locally Attached Storage (DAS): DAS storage architecture featured disks and arrays that are locally attached to the Exchange Server and are commonly supported by Microsoft Exchange 2013 and include Serial ATA (SATA) and SCSI hardware architectures.
  • Storage Area Networks (SANS): SAN architecture is fully supported in Microsoft Exchange 2013 both over Fibre and iSCSI interfaces.
    • Microsoft recommends that you allocate dedicated volumes (spindles) to Exchange Server and not share the same underlying physical disks with other applications on your SAN.  This recommendation is in support of ensuring that you have reliable and predictable storage performance for Exchange and not have to worry about resource contention and bottlenecks that may be common in poorly designed or managed SAN environments.
    • Fibre-channel over Ethernet (FCoE): Microsoft has yet to release any design information pertaining to whether Exchange 2013 supports implementations of FCoE. While technically, FCoE should have no issues supporting the latency requirements and frame sizes of an Exchange 2013 environment, I would recommend that you proceed with caution when implementing any Microsoft technology over a non-supported environment. In the event of a support incident, Microsoft support has the right to declare that your environment is non-supportable due to inconsistencies with their Hardware Compatibility list (HCL).
  • Network Attached Storage (NAS): At this point in time, Exchange Server 2013 does not suppor the use of NAS-based storage devices for either Physical or Virtual implementations of Exchange.

Allocating Storage

Let’s start with the basic storage requirements of Exchange Server 2013. Microsoft indicates that Exchange 2013 requires that you allocate the following amount of storage space to accommodate the following Storage Types:

  • Exchange System Volumes: At least 200 MB of available disk space on the system drive
  • Exchange binaries: At least 30GB of free space on the drive you wish to install the Exchange binaries on. With an additional 500 MB of available disk space for each Unified Messaging (UM) language pack that you plan to install
  • Exchange Database Volumes: Amount of storage required would vary depending on a number of factors including the number of and size of mailboxes in your organization, the mailbox throughput (average number of emails sent/received), high availability features (database copies), as well as email retention policies (how long you need to store emails). These factors will determine an optimal number of mailboxes per database, number of databases and database copies and finally the amount of storage allocated for growth.
  • Exchange Database Log Volumes: You should provision sufficient storage to handle the transaction log generation volume of your organization. Factors that affect the rate of transaction log generation include message throughput (number of sends/receives), size of message payloads and high-availability features such as database copies. If you plan to move mailboxes on a regular basis, or need to accomodate large numbers of mailbox migrations (import/export to Exchange), this will result in a higher number of transaction logs generated. If you implement lagged database copies, then you need to provision additional storage on the transaction log volume for the number of days of lag you have configured. The following requirements exist for log file truncation when lagged copies are configured:
    • The log file must be below the checkpoint for the database.
    • The log file must be older than ReplayLagTime + TruncationLagTime.
    • The log file must have been truncated on the active copy.
  • Message Queue Database: A hard disk that stores the message queue database on with at least 500 MB of free space.

Volume Configuration

Microsoft recommends the following configuration settings for each volume that hosts Exchange-related data:

  • Partitioning: GPT is a newer technology over traditional MBR partitioning formats to accommodate much larger disk sizes (up to 256 TB), While MBR is supported, Microsoft Recommends that you use GPT partitions to deploy Exchange. Partitions should also be  aligned to 1MB.
  • File System: NTFS is the only supported file system type supported by Exchange 2013. Microsoft recommends an optimal allocation unit size of 64KB for both Exchange Database and Log File volumes. NTFS features such as NTFS Compression, Defragmentation and Encrypted File System (EFS) are not supported by Exchange 2013.
  • Windows BitLocker: BitLocker is a form of Drive Encryption supported in newer versions of Microsoft Windows. BitLocker is supported for all Exchange Database and Log File volumes. However, there is limited supportability for Windows BitLocker on Windows Failover Clusters. Link here.
  • SMB 3.0: SMB is a Network File Sharing Protocol over TCP/IP with the latest version available in Windows Server 2012. SMB 3.0 is only supported in limited deployment configurations of Exchange 2013, where fixed virtual hard disks (VHDs) are provisioned via sMB 3.0 only in the Windows Server 2012 Hyper-V or later version. Direct storage of Exchange data is not supported on SMB. Read this article.

Storage Best Practices

The following best practices offer useful guidelines on how to configure your Exchange 2013 Environment

  • Large Disk Sector Sizes: With ever-increasing disk capacities in excess of 3TB, hardware manufacturers have introduced a new physical media format known as Advanced Format that increases physical sector sizes. Recent versions of the Windows Operating System, including Windows Vista, Windows 7 and Windows Servers 2008, 2008 R2 and 2012 with certain patches applied (link) support a form of logical emulation known as 512e which presents a logical sector size of 512k, whereas the physical hardware can actually read or write to a larger sector size, known as atomicity.
  • Replication homogeneity: Microsoft does not support Exchange databases copies that are stored across different disk types. For example, if you store one copy of an Exchange database on a 512-byte sector disk, you should not deploy database copies to volumes on another Exchange server that are configured with a different sector size (commonly 4KB).
  • Storage Infrastructure Redundancy: If you choose externally attached storage such as a SAN solution, Microsoft recommends that you implement multi-pathing or other forms of path redundancy in order to ensure that the Exchange  Server’s access to the storage networks remains resilient to single points of failure in the hardware and interconnecting infrastructure (Ethernet for iSCSI and Fibrechannel for conventional SCSI-based SANs).
  • Drive Fault Tolerance: While RAID is not a requirement for Exchange 2013, Microsoft still recommends RAID deployments especially for Stand-alone Exchange servers. The following RAID configurations are recommended based on the type of storage:
    • OS/System or Pagefile Volume: RAID 1/10 is recommended, with dedicated LUNs being provisioned for the System and Page file volumes.
    • Exchange Database Volume: For standalone (non-replicating) Servers, Microsoft recommends deploying a RAID 5 with a maximum array size of 7 disks and surface scanning enabled. For larger array sizes, Microsoft recommends deploying RAID 6 (5+1) for added redundancy. For high-availability configurations with database replication, redundancy is provided by deploying more than one copy of any single Exchange Database, therefore Microsoft recommends less stringent hardware redundancy requirements. You should have at least 2 or more lagged copies of each database residing on separate servers and if you can deploy three or more database copies, you should have sufficient database redundancy to rely on JBOD (Just a Bunch of Disks) storage. The same recommendations for RAID 5/6 apply for high-availability configurations. In both cases of standalone and high-availability configurations that use slower disk speeds (5400 – 7200 rpm), Microsoft recommends deploying disks in a RAID 1/10 for better performance.
    • Exchange Mailbox Log Volumes: For all implementations, Microsoft supports all RAID types, but recommends RAID 1/10 as a best practice, with JBOD storage only being used if you have at least three or more replica copies of an Exchange Database. If deploying lagged database copies, you should implement JBOD storage only if you have two or more copies of a database.
    • RAID configuration parameters: Furthermore, Microsoft recommends that any RAID array be configured with a block size of 256KB or greater and with storage array cache settings configured for 75% write cache and 25% read cache. Physical disk write caching should be disabled when a UPS is not in use.
  • Database volume size and placement: Microsoft Exchange Server 2013 supports database sizes of up to 16TB, however for optimal database seeding, replication and restore operations, Microsoft recommends that you limit each database size to 200GB and provision the size of each volume to accommodate a 120% of the maximum database size.
  • Transaction Log volume size and placement: Microsoft recommends implementing Database and Log file isolation by deploying your database files and transaction log files in separate volumes. This is actually a good practice, since the performance requirements of databases and transaction logs differ.
  • Basic and Dynamic Disk types: The Windows Operating System supports a form of  disk initialization known as Dynamic Disks, which allows you to configure options such as software-based RAID and dynamic volume sizes. While Dynamic Disks are a supported storage type in Exchange 2013, Microsoft recommends that you deploy Exchange on the default Basic Disk storage.


In this section, we explored the various storage components supported by Microsoft Exchange Server 2013 and reviewed some deployment best practices for implementing Exchange. There are a number of different types of storage that the various components of Exchange utilize and a well architected storage solution should seek to optimize performance of these various components.


Link to Microsoft Technet article on Storage Configuration Options.

Article on MSDN site on Windows support for Advanced Format disk types

Link to Microsoft Technet article on Virtualization Support

Exchange 2013 Brief – Data Loss Prevention (DLP)

Executive Overview

DLP capabilities help you protect your sensitive data and inform users of your policies and regulations. DLP can also help you prevent users from mistakenly sending sensitive information to unauthorized people. When you configure DLP polices, you can identify and protect sensitive data by analyzing the content of your messaging system, which includes numerous associated file types. The DLP policy templates supplied in Exchange 2013 are based on regulatory standards such as PII and payment card industry data security standards (PCI-DSS). DLP is extensible, which allows you to include other policies that important to your organization. Additionally, the new Policy Tips capability allows you to inform users about policy violations before sensitive data is sent.

Notable Features

  • DLP Policies
  • Sensitive Information Types
  • Policy Detection and Reporting
  • Policy Tips


The transport rule agent (TRA) is used in Exchange 2013 to invoke deep message content scanning and also to apply policies defined as part of Exchange Transport Rules.

  • DLP Policies: These policies contain sets of conditions which comprise of Transport rules, actions and exceptions. Conditions can be configured from scratch or modified from pre-existing policy templates in Exchange 2013. There are three supported methods to create DLP policies:
    • Create a DLP policy from an existing policy template: At the time of writing, Exchange 2013 supports over 40 policy templates to support a number of compliance requirements from various Countries and jurisdictions such as GLB and PCI-DSS.
    • Import a pre-built policy file from outside your organization: Exchange 2013 allows organizations to use DLP policies created by independent software vendors by importing these policies directly into Exchange as XML files. To define your own DLP policy template files, you must first define an XML schema (read here; then you can define sensitive information rule types (read here).
    • Create a custom policy from scratch: Exchange 2013 provides the granularity to define a DLP policy to match an organization’s requirements for monitoring certain types of data.
  • Sensitive Information Types: DLP now has the ability to perform deep content analysis via keyword matches, dictionary matches, regular expression evaluation, and other content examination to detect content that violates organizational DLP policies. Sensitive information rule types augment the existing transport rules framework and allow you to apply messaging policies to email messages that flow through the transport pipeline in the Transport service on Mailbox servers and on Edge Transport servers. Read my article on Exchange Transport architecture.
  • Policy Detection and Reporting: Exchange 2013 provides availability and access to information that identifies policy violations occurring within the DLP environment. This information is made available via the Message Tracking Logs. The AgentInfo Event is used to add DLP related entries in the message tracking log. A single AgentInfo event will be logged per message describing the DLP processing applied to the message. An incident report can be created for each DLP policy rule set via the Generate Incident Report feature in the EAC.
  • Policy Tips: enable you to notify email senders that they are about to violate one of the  DLP policies before they send the offending message. Click here for more information.

Common Administrative Tasks

  1. Create a DLP policy from a Template: To use existing templates, the DLP must be configured via the EAC. Read this article.
  2. Import a DLP policy from a File: Via EAC or PowerShell
    Import-DlpPolicyCollection -FileData ([Byte[]]$(Get-Content -Path ” C:DocDLP Backup.xml ” -Encoding Byte -ReadCount 0))
  3. Create a custom DLP policy without any rules: This must be configured via EAC
  4. Export a DLP policy:  Via EAC or PowerShell
  5. Create a custom DLP policy: Via EAC or PowerShell
    New-DlpPolicy “Employee IDs”
  6. View details of an existing DLP policy: Via EAC or PowerShell
    Get-DlpPolicy “Employee IDs” | Format-List
  7. Change a DLP policy: Via EAC or PowerShell
    Set-DlpPolicy “Employee IDs” -Mode (Audit|AuditAndNotify|Enforce)
  8. Delete a DLP policy: Via EAC or PowerShell
    Remove-DlpPolicy “Employee IDs”
  9. Import/Export a DLP policy: Via EAC or PowerShell
  10. Manage Policy Tips: Via EAC, for more information click here.
  11. Create a New Classification Rule Collection: via PowerShell
    New-ClassificationRuleCollection -FileData ([Byte[]]$(Get-Content -Path “C:DocExternal Classification Rule Collection.xml” -Encoding Byte -ReadCount 0))
    † This action overwrites all pre-existing DLP policies that were defined in your organization, so make sure you backup your current DLP policy information first.

Top PowerShell Commands/Tools:

– Set|Get|New|Remove -DlpPolicy
– Set|Get|New|Remove -ClassificationRuleCollection
– Export|Import -DlpPolicyCollection


Command Reference for DLP
Microsoft Technet page on DLP in Exchange 2013

Exchange 2013 Briefs – In-place eDiscovery

Executive Overview

In-Place eDiscovery allows you to search mailbox data across your Exchange organization, preview search results, and copy them to a Discovery mailbox. Users in the Discovery Management role group can be delegated access to perform discovery searches without the need to grant them elevated privileges.

Notable Features

  • Exchange Search and Keyword Query Language (KQL)
  • Discovery Management Role group
  • Discovery Mailboxes
  • Discovery Search Actions
  • eDiscovery Center


In-Place eDiscovery in Exchange 2013 supports

  • Exchange Search and Keyword Query Language (KQL): The content indexing feature of Exchange Search has been redesigned to provide greater integration with Microsoft Search Foundation and Microsoft Sharepoint 2013. By exposing the powerful federated search capabilities included in Sharepoint 2013, users can easily structure complex and efficient search queries. This article explains the Keyword Query Language (KQL) capabilities and syntax of Sharepoint 2013.
  • Discovery Management Role group: This group consists of two management roles; the  Mailbox Search Role, which allows a user to perform an In-place eDiscovery search; and the Legal Hold Role, which allows a user to place a mailbox in In-place hold or Litigation hold.
  • Discovery mailboxes: These are used during In-place eDiscovery Searches as target mailboxes and the results of In-place eDiscovery Searches and be copied to these mailboxes. Discovery mailboxes cannot be repurposed as other types of mailboxes.
  • Discovery Search Actions: Users can perform the following actions during a discovery search:
    • Estimate search results: Obtain an estimate of the total size and number of items that will be returned by the search based on search criteria. Estimates are displayed in the details pane.
    • Preview search results: Preview the results of a search by displaying messages returned from each mailbox searched.
    • Copy search results:  Copy messages returned in search results to a Discovery mailbox.
  • eDiscovery Center: The eDiscovery Center site collection is part of SharePoint 2013 and provides features to help with the first half of the eDiscovery Reference Model (EDRM)—identification, preservation, collection, processing, and analysis; and is available on-premises or in the cloud. Using the eDiscovery Center, you can perform searches across SharePoint, Exchange and Lync content archived into Exchange. Click here for a great article on eDiscovery in Sharepoint.

Common Administrative Tasks

  1. Add a user to the Discovery Management Role Group: In EAC or PowerShell
    Add-RoleGroupMember -Identity “Discovery Management” -Member “Road Chimp”
    This can be verified via the command: Get-RoleGroupMember -Identity “Discovery Management”
  2. Create a Discovery Mailbox via the command:
    New-Mailbox SearchResults01 -Discovery -UserPrincipalName
  3. Create an In-place eDiscovery Search: In EAC or PowerShell
    New-MailboxSearch “Discovery-CaseID001” -StartDate “01/01/2012” -EndDate “12/01/2012” -SourceMailboxes “DG-Finance” -TargetMailbox SearchResults01 -SearchQuery ‘”Bananas” AND “Peel”‘ 
  4. Preview an In-place eDiscovery Search: In EAC or PowerShell
    Start-Mailbox Search -EstimateOnly….
  5. Start/Stop an In-place eDiscovery Search: In EAC or PowerShell
    -Identity “Discovery-CaseID001”  to start &
    Stop-MailboxSearch -Identity “Discovery-CaseID001”  to stop
  6. Retrieve the status of an In-place eDiscovery Search: In EAC or PowerShell
    Get-MailboxSearch “Discovery-CaseID001” 
  7. Modify an In-place eDiscovery Search: In EAC or PowerShell
    Set-MailboxSearch -Identity “Discovery-CaseID001” -SourceMailboxes “DG-Executives”
  8. Remove an In-place eDiscovery Search: In EAC or PowerShell
    Remove-MailboxSearch -Identity “Discovery-CaseID001
  9. Re-create the Discovery System Mailbox: Click here for more information.
  10. Configure Exchange for Sharepoint eDiscovery Center: Click here for steps.

Top PowerShell Commands/Tools

– Add-RoleGroupMember
– New-MailboxSearch
– Start-MailboxSearch
– Stop-Mailbox Search
– Get-Mailbox Search
– Set-Mailbox Search

Command Reference for eDiscovery Search
Microsoft Technet page on eDiscovery
Article on Keyword Query Language
Technet blog writeup on eDiscovery Search

Exchange 2013 Brief – Information Rights Management

Executive Overview:

Information Rights Management (IRM) features in Exchange 2013 are used to prevent information leakage or loss of potentially sensitive information, which can be costly to an organization and include financial loss, erosion of competitive advantage and damage to image and credibility.

Notable Features:

  • Active Directory Rights Management Services (RMS)
  • AD RMS Rights Policy Templates
  • Outlook/Transport Protection Rules
  • E-mail/ OWA & ActiveSync support
  • In-place eDiscovery support
  • Hybrid and Cross-forest deployments


IRM features are deployed in conjunction with Microsoft Active Directory Rights Management Services (AD RMS). Using policy templates, an administrator can quickly deploy a wide array of policies to protect and secure potentially-sensitive data across a variety of client access methods (Outlook/OWA/ActiveSync), while still providing full support for eDiscovery and Journaling processes.

  • AD RMS rights policy templates: RMS rights policy templates are XrML documents that contain a predefined usage policy that can be applied to protect an item of content. Templates can contain the following information:
    • A template name and description.
    • Users and groups that can be granted content licenses.
    • The rights and associated conditions granted to the users.
    • The content expiration policy.
    • A set of extended policies.
    • The template revocation policy.
    • A revocation list.
    • A revocation list refresh interval.
    • A public key file for the revocation list.
  • IRM Agents: IRM is implemented in Exchange 2013 using transport agents in the Transport service on a Mailbox server. Agents include the following (RMS Decryption Agent | Transport Rules Agent | RMS Encryption Agent | Prelicensing Agent | Journal Report Decryption Agent
  • Transport Protection Rules: A transport protection rule is used to apply persistent rights protection to messages based on properties such as sender, recipient, message subject, and content.
  • Outlook Protection Rules: An AD RMS template can be applied to Outlook 2010 or other RMS-enabled applications in order to protect messages before they are sent.
  • Transport Decryption: This feature allows the Transport Service to inspect the content of an IRM protected message in order to apply policies or rules to the message.
  • In-place eDiscovery: You can configure IRM to allow Exchange Search to index IRM-protected messages, in order to support an In-place eDiscovery search that is performed by members of the Discovery Management role group.
  • Journal report Decryption: This allows the Journaling agent to attach a decrypted copy of a rights-protected message to the journal report. This requires the Federated Delivery mailbox to be added to the super users group on the AD RMS server.
  • IRM in OWA: The following IRM functionality is available from OWA (Send/ Read IRM-protected messages | Send IRM protected attachments | WebReady Document Viewing
  • IRM in Exchange ActiveSync: Organizations can use Information Rights Management (IRM) to apply persistent protection to messaging content when accessed from mobile devices. Mobile device users can create/read/reply to and forward IRM-protected messages.

Common Administrative Tasks:

  1. Configuring IRM: Set-IRMConfiguration: Set-IRMConfiguration -InternalLicensingEnabled $true
  2. Create a Transport Protection Rule: via EAC or Cmdlet
    Retrieve all RMS templates: Get-RMSTemplate | format-list
    Create rule: New-TransportRule -Name “New rule” -SubjectContainsWords “Dirty Bananas” -ApplyRightsProtectonTemplate “Do Not Forward”
  3. Create an Outlook Protection Rule: New-OutlookProtectionRule -Name “Project Bananasplit” -SentTo “” -ApplyRightsProtectionTemplate “Business Critical”
  4. Add the Federation System Mailbox to AD RMS Super Users Group :
    Create a dedicated Super User Group: New-DistributionGroup -Name ADRMS SuperUsers -Alias “ADRMS Super Users”
    Add the Federated system mailbox to the group: Add-DistributionGroupMember ADRMSSuperUsers -Member FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042
  5. Enable/Disable Transport Decryption: Set-IRMConfiguration -TransportDecryptionSetting Mandatory
  6. Enable IRM to support In-place eDiscovery:
    Enable Exchange Search:  Set-IRMConfiguration -SearchEnabled $true
    Enable eDiscovery: Set-IRMConfiguration -EDiscoverySuperUserEnabled $true
  7. Enable/Disable Journal Report Decryption: Set-IRMConfiguration -JournalReportDecryptionEnabled $true
  8. Enable/Disable IRM OWA support:
    Configure on each OWA Virtual Directory: Set-OWAVirtualDirectory -IRMEnabled $true
    or Configure on each OWA Mailbox Policy: Set-OWAMailboxPolicy -IRMEnabled $true
  9. Enable/Disable IRM Exchange ActiveSync support:
    Add the Federation System Mailbox to AD RMS Super Users Group (Step 4)

Top PowerShell Commands/Tools:

 – Set/Get-IRMConfiguration
– Get-RMSTemplate
– New/Get-TransportRule (ApplyRightsProtectionTemplate)
– New/Get-OutlookProtectionRule
– Test-IRMConfiguration


Technet: Information Rights Management
Technet: Common IRM tasks
Technet: Configure permissions
Cmdlets: Messaging policy and compliance
Reference: AD RMS Rights Policy Templates
List of supported file types covered by IRM policies when attached to messages

Exchange 2013 Briefs

Hi all! The thought hit me that Exchange has become such a massive beast that it can be extremely daunting for someone to pick up the technology from scratch.

So I’ve decided to put together a compilation of Exchange Briefs: short documents that contain a basic summary of a specific component/feature of Exchange and some links to resources and beyond.

I’ll try to standardize the format of each brief:

  • Executive Overview
  • Architecture/Components
  • Notable Features
  • Common Administrative Tasks
  • Top PowerShell Commands/Tools:
  • References/Links

List of Briefs
This list will probably change and once I post a brief, I will link to it from here.

1. Exchange Unified Messaging
2. Site Resilience
3. Information Rights Management
4. Mailbox and Administrative Auditing
5. In-Place Archiving
6. Data Loss Prevention
7. Message Records Management
8. In-place eDiscovery
9. In-place Hold
10. Coexistence with Exchange Online (Hybrid)
11. Coexistence with Legacy Systems
12. Cross-Forest Coexistence
13. Exchange Federation

This project might take a while, so please drop some comments or requests and  I will try to get to them!

Chimp’s Update: I’ve uploaded all of the Exchange 2013 components for Messaging and Compliance, numbered 3-9.

Ook… Road Chimp

Exchange 2013 Architecture Series – Part 1: Message Transport

In this first article of our Exchange Architecture Series, we will explore the new Transport Architecture of Exchange 2013. I’ll try not to repeat a lot of information that is stored on other Sources unless I believe that there is a lot of value to having it in my posting.

The Transport Pipeline
The transport pipeline is a new concept introduced in Exchange 2013 to describe the collection of services, connections, components, and queues that work together to route all messages to the categorizer in the Transport service on a Mailbox server inside the organization.

The transport pipeline comprises of three primary services that have been deployed either on a Mailbox Server role or on a Client Access Server role. (Note that in Exchange 2013,  the Hub Transport and Front End Server roles have been removed)

  • Front End Transport service (CAS role): This service runs on all Client Access servers and acts as a stateless proxy for all inbound and outbound external SMTP traffic for the Exchange 2013 organization. The Front End Transport service can filter and route messages based on policy rules, but cannot inspect message content. This service communicates with the Transport service on a Mailbox server, and doesn’t queue any messages locally.
  • Transport service (Mailbox role): This service runs on all Mailbox servers and replaces the Hub Transport server role in previous versions of Exchange. The Transport service manages all SMTP mail flow for the organization, (includes message categorization and content inspection). This service routes messages between i) the Front End Transport service; ii)the Transport service on other servers; and iii) the Mailbox Transport service.
  • Mailbox Transport service (Mailbox role): This service runs on all Mailbox servers and consists of two separate services:
    i) Mailbox Transport Submission service: connects to the local mailbox database using RPC to retrieve messages, and submits the messages over SMTP to the Transport service on the local Mailbox server, or on other Mailbox servers. Accesses the same routing topology information as the Transport Service and also does not queue any messages locally.
    ii) Mailbox Transport Delivery service: receives SMTP messages from the Transport service on the local Mailbox server or on other Mailbox servers, and connects to the local mailbox database using an Exchange remote procedure call (RPC) to deliver the message.

The transport pipeline is illustrated below (source)

Inbound Mailflow Steps:
It’s easier to describe this architecture by tracing how an email from an external sender gets to your mailbox. The steps are as follows:

1. An email message arrives over the internet via SMTP and gets processed by the SMTP Receive connector within the Front End Transportservice running on an Internet-facing CAS Server†.
2. The Front End Transport service inspects the message header and performs some routing logic. In this case, the message is routed to a Mailbox Server in the same site and transmitted via the SMTP Send component of the Front End Transport service.
3. The SMTP Receive connector of the Transport service on the target Mailbox Server receives the message and performs message content inspection; applies transport rules; and performs anti-spam and anti-malware inspection if they are enabled.
4. Every message that is isn’t rejected by the Transport service must then be categorized. It is first placed in the submission queue.
5. The categorizer picks up one message at a time for categorization, performing the following steps:

  • Recipient resolution (includes top-level addressing, expansion, and bifurcation)
  • Routing resolution
  • Content conversion
  • Applying relevant mailflow rules

6. Messages are then placed in a delivery queue that’s based on the destination of the message. (Exchange 2013 has a more granular queuing model that is based on destination mailbox database, DAG, Active Directory site, Active Directory forest or external domain)
7. The message is finally transmitted via the SMTP Send connector to a routing destination, which in this case is the Mailbox Transport Delivery service running on the same server††.
8. The Mailbox Transport Delivery service receives the message and submits it to the Store Driver, which instructs the Mailbox Deliver Agents to submit the messages to the individual mailboxes.

†There are multiple ways by which messages can enter the Transport service on a Mailbox server, including

  • Through a Receive connector.
  • From the Pickup directory or the Replay directory.
  • From the Mailbox Transport service.
  • Through agent submission.

††There are also multiple routing destinations that a mailbox transport service can route emails, including

  • Another Mailbox Server that’s part of the same DAG
  • The Transport service running on another Mailbox Server that’s in a different DAG, Active Directory site, or Active Directory forest
  • The Front End Transport service on a CAS server for delivery to the Internet

In this post, we got to see how a message is treated as it enters an Exchange organization and eventually gets delivered to a user’s mailbox. In the next post, we will explore how Exchange 2013 routes messages.

Exchange 2013 in Azure Part 4 (Post-Install Configuration)

Okay, so now that we have completed the installation of Exchange 2013 in our environment, it looks like we have a couple more steps before we can actually get email flowing and our users logging in to check their email.


1. Verify that your installation completed successfully
Before you start configuring the features of Exchange 2013, it’s best to make sure that the installation completed successfully. In order to do so, it’s recommended to perform the following steps:

2. Restart the Server
A server reboot is required for your Exchange Server to properly register and startup all of it’s required services and dependencies. Some organizations configure policies explicitly preventing automatic reboots of servers. Please make sure that your server has rebooted after the installation.

3. Verify the correct build/version of Exchange is installed
From PowerShell, run the command: Get-ExchangeServer | Format-List. The output returned will indicate the version number of Exchange installed on the server as well as any installed patches. For more information of this command, click here. For the Preview release version of Exchange 2013, the build number is 15.0,516,32. Here’s a great link that shows all of the Build numbers for the different versions of Exchange Server.

4. Check logs for errors
View the application logs on the server under Event Viewer as well as the ExchangeSetup.log file in the C:ExchangeSetupLogs folder of the Exchange Server using any text editor. You can perform a search to match the strings “Error” or “Failed”. This will help you to identify any potential errors. Be sure to visit the Microsoft Technet Exchange 2013 forums here to seek help from the awesome online community. (‘I have done so many a time’, says Road Chimp)

The Exchange Administration Center

In Exchange 2013, you have the option of configuring Exchange 2013 via a GUI using the Exchange Administration Center (EAC) or via the Exchange Management Shell. The EAC is a new web-based management interface that is a vastly improved version of the Exchange Control Panel that debuted in Exchange 2010.

To get started with the EAC, you can first find out the URL of your EAC by typing the following command in PowerShell:

Get-EcpVirtualDirectory | fl *URL*

The EAC URL should look something like Note that the URL ends in ‘ECP’ which is probably a throwback to the ECP in Exchange 2010. You can launch the EAC from a browser. Don’t forget to login via a domain user account and password.

Configuration Steps

So now we’re ready to begin configuring our Exchange 2013 Server. In this section we will configure the following:

1. Create a Send Connector
2. Configure Receive Connector
3. Add additional accepted domains
4. Configure the default email address policy
5. Configure an SSL certificate
6. Configure External URLs
7. Configure DNS

Now, on to our first configuration task:

1. Create a Send Connector

A Send Connector allows you to provide Exchange with instructions on how to send emails outside of your organization. For example, you can define that emails  intended for a specific recipient domain can get routed to a specific endpoint server, or simply you can configure the Send Connector to use DNS to make routing decisions for you. To configure a Send Connector via the following steps:

Click on Mail flow > Send connectors.

On the Send connectors page, click AddAdd Icon, which launches the New Send Connector wizard.

I specified the name “Default Internet” for the send connector. You have four options to select and each selection determines the default permission sets that are assigned on the connector and grants those permissions to trusted security principals (users, computers, security groups etc.).

The options are:

  • Custom: Typically when you want to when you want route messages to computers not running Microsoft Exchange Server 2013. You can choose to route mail through smart hosts running SMTP. Microsoft recommends that if you use basic authentication, you use an encrypted connection because the username and password are sent in clear text.
  • Internal: Allows you to send intranet mail
  • Internet: Allows you to send internet mail
  • Partner: Routes mail to allow connections only to 3rd party servers that authenticate with TLS certificates.

For our lab demo, I selected Internet and then clicked Next.

In the next screen, ensure that “MX record associated with recipient domain” is select and click Next.

This indicates that the connector uses DNS to route mail. Your other option is to route mail through a smart host*, which could be a dedicated SMTP server or cloud-hosted service that your organization uses to send all out-bound email (and perhaps perform malware and virus scanning).

* The “Use the external DNS lookup settings on servers with transport roles” may be used if you have both external and internal DNS zone files for a domain you need to route mail to and you want emails to be routed via the internet. I left this option unchecked.

Under Address space, click Add+. Select SMTP in the Type field and enter * in the Fully Qualified Domain Name (FQDN) field, with a cost of 1. Click Save.

Note: The Scoped send connector checkbox indicates that this connector is scoped to a specific group of servers (a delivery group) and only this group is allowed to route messages to destination defined by the connector. This delivery group may contain Exchange 2010 Hub Transport servers or Exchange 2013 Mailbox servers located in different Active Directory sites. Ensure that the checkbox isn’t selected and then click Next.

Under Source server, click AddAdd Icon. In the Select a server window, select a Mailbox server that will be used to send mail to the Internet via the Client Access server. I’ve selected my mailbox server CHIMPLABEXMB01. After you’ve selected the server, click Add and then click OK. Now you can click Finish to complete the wizard.

– Optional: Configure the Mailbox Server to proxy outbound messages through a Client Access Server .  We can perform this task through the shell by typing in the command:

     Set-SendConnector “Default Internet ” –FrontendProxyEnabled

By setting this command, you’re effectively configuring the behavior of the Transport service on the Mailbox servers to route outbound mail through the Front End Transport service on the CAS servers in the local Active Directory site. This is NOT set by default and is a good practice to consolidate and simplify mail flow, especially in large environments.

Simply typing Set-SendConnector provides more information on how to set parameters on a Send connector. It’s useful to note that the default maximum message size, specified by the MaxMessageSize parameter, has been increased from 10MB to 25MB. Another parameter TlsCertificateName has been added. It is used to authenticate the local certificate to be used for outbound connections and minimize the risk of fraudulent certificates.

*Note on SMTP Relays
In the old days, many organizations used to expose their Exchange servers directly to the Internet. Nowadays, you would have either an SMTP mail appliance (Anti-Spam/ Malware) or Cloud subscription service that relays inbound emails to your CAS server. As there is no Edge Server support in Exchange 2013, you might want to hold on to your Exchange 2010 Edge Servers for now! Also, you will need to ensure that inbound SMTP is configured on your firewall to enable your SMTP edge devices to relay emails into your CAS servers.

– You can verify that this works by logging in to Outlook Web App ( with a valid user account and sending an email to an external recipient.

2. Configure Receive Connector

A receive connector listens for inbound connections that match the settings of a receive connector through a particular IP address and port and from a specified address range.  You can configure multiple receive connectors to control which servers receive messages from a particular IP address or IP address range. A receive connector can be created on a Mailbox Server running the Transport service or a Client Access Server running the Front End Transport service.

receive connectors are configured automatically after you install a Mailbox Server running the Transport Service in Exchange 2013. They are:

  • Default<server name> Accepts connections from Mailbox servers running the Transport service and from Edge servers.
  • Client Proxy <server name> Accepts connections from front-end servers. Typically, messages are sent to a front-end server over SMTP.

Three receive connectors are configured automatically after you install a Client Access Server running the Frontend Transport Service in Exchange 2013. They are:

  • Default FrontEnd <server name> Accepts connections from SMTP senders over port 25. This is the common messaging entry point into your organization.
  • Outbound Proxy Frontend <server name> Accepts messages from a Send Connector on a back-end server, with front-end proxy enabled.
  • Client Frontend <server name> Accepts secure connections, with Transport Layer Security (TLS) applied.

Each connector is assigned a TransportRole value. You can use it to determine the role the connector is running in. This can be helpful in cases where you are running multiple roles on a single server. In the case of each Receive connector running on a Mailbox Server, their TransportRole value is HubTransport. For each Receive connector running on a Client Access Server, their TransportRole value is FrontEndTransport. You can view this information by typing the Get-ReceiveConnector command.

3. Add additional accepted domains

By default, Exchange uses the domain name of the Active Directory Domain where the setup /PrepareAD command was run prior to installing Exchange. Your Organization may want to use a different email address to send and receive emails from. Perform the following steps to configure an accepted domain:

From EAC, click on Mail flow > Accepted domains. On the Accepted domains page, click AddAdd Icon. Specify a name for the accepted domain in the New accepted domain wizard. Now specify the SMTP recipient domain you want to add in the Accepted domain field. If this Exchange Server will be receiving all emails for the domain that you just added, select Authoritative domain and then click Save.

4. Configure the default email address policy

A couple of posts back, we explored the setup PrepareSchema command and how it extends the schema to provide support for mail-enabled objects in Active Directory.  The default email address policy enables you to setup rules to assign every recipient in your organization with a default email address based on the accepted domain that you configured previously. For example:

If you added an accepted domain in the previous step and you want that domain to be added to every recipient in the organization, you need to update the default email address policy. Perform the following steps in the EAC:

Go to Mail flow > Email address policies. On the Email address policies page, select Default Policy and then click EditEdit Icon.

Click Email Address Format on the Default Policy Email Address Policy page. Click the SMTP address you want to change and then click EditEdit IconUnder Email address format. Specify the SMTP recipient domain you want to apply to all recipients in the Exchange organization.

On the Email address format page in the Email address parameters field. (This domain must match the accepted domain you added in the previous step.) Click Save.

Click Save again and then click Apply in the Default Policy details pane.

You can verify that this works by selecting a mailbox in EAC (Recipients>Mailboxes) and verifying  that the User Mailbox field has been set to Alternatively, you can try creating a mailbox in EAC (Recipients>Mailboxes and Add+). You can now provide all the information required to create a new mailbox.

5. Configure an SSL certificate

Services such as Outlook Anywhere and ActiveSync require certificates to be configured on your Exchange 2013 server. The following steps show you how to configure an SSL certificate from a third-party certificate authority (CA):

– Go to Servers > Certificates. On the Certificates page, select the Client Access server in the Select server field, and then click AddAdd Icon
– This launches the New Exchange certificate wizard. Now select Create a request for a certificate from a certification authority and then click Next.
– Specify a name for this certificate then click Next.
– You can request a wildcard certificate by selecting Request a wild-card certificate and then specifying the root domain of all subdomains in the Root domain field. Alternatively, leave this page blank and click Next.
– Click Browse and specify an Exchange server to store the certificate on. You must select an Internet-facing Client Access server. Click Next.
– For each service in the list shown, specify the external or internal server names that users will use to connect to the Exchange server. For example, for Outlook Web App (when accessing over the Internet), you might specify For OWA (when accessing over the Intranet), you might specify These domains will be used to create the SSL certificate request. Click Next.
– Add any additional domains you want included on the SSL certificate. Click Next.
– Provide information about your organization. This information will be included with the SSL certificate. Click Next.
– Specify the network location where you want this certificate request to be saved. Click Finish.

After you’ve saved the certificate request, submit the request to your certificate authority (CA). This can be an internal CA or a third-party CA, depending on your organization. Clients that connect to the Client Access server must trust the CA that you use. After you receive the certificate from the CA, complete the following steps:

– On the Server > Certificates page in the EAC, select the certificate request you created in the previous steps.
– In the certificate request details pane, click Complete under Status.
– On the complete pending request page, specify the path to the SSL certificate file and then click OK.
– Select the new certificate you just added, and then click EditEdit Icon.
– On the certificate page, click Services.
– Select the services you want to assign to this certificate. At minimum, you should select SMTP and IIS. Click Save.
– If you receive the warning Overwrite the existing default SMTP certificate?, click OK.

To verify that you have successfully added a new certificate, do the following:
– In the EAC, go to Servers > Certificates.
– Select the new certificate and then, in the certificate details pane, verify that the following are true:
Status shows Valid
Assigned to services shows IIS and SMTP

6. Configure External URLs

Now that you’ve published the external domain names in a certificate and installed them into Exchange, you need to configure the external domains on the Client Access server’s virtual directories and then configure your domain name service (DNS) records.

The steps below configure the same external domain on the external URL of each virtual directory. To configure different external domains on one or more virtual directory external URLs, you will have to configure the external URLs manually. For more information, see Virtual Directory Management.

– Go to Servers > Servers and then click on the Wrench > Configure external access domain.
– Under Select the Client Access servers to use with the external URL, click AddAdd Icon
– Select the Client Access servers you want to configure and then click Add. After you’ve added all of the Client Access servers you want to configure, click OK.
– In Enter the domain name you will use with your external Client Access servers, type the external domain you want to apply, for example: Click Save.
– Go to Servers > Servers, select the name of the Internet-facing Client Access server (CHIMPLABEXCA01 in my case) and then click EditEdit Icon.
– Click Outlook Anywhere.
In the Specify the external hostname field, specify the externally accessible FQDN of the Client Access server. For example, You can also verify the internal FQDN that users will access the host from .Click Save.

7. Configure DNS

After you’ve configured the external URL on the Client Access server virtual directories, you need to configure DNS records for Autodiscover, Outlook Web App, and mail flow. The DNS records should point to the external IP address of your Internet-facing Client Access server and use the externally accessible FQDNs that you’ve configured on your Client Access server. The following are examples of recommended DNS records that you should create to enable mail flow and external client connectivity.

FQDN DNS record type Value MX A <external ip> A <external ip> A <external ip>

To verify that you have successfully configured the external URL on the Client Access server virtual directories, do the following:

– In the EAC, go to Servers > Virtual directories.
– In the Select server field, select the Internet-facing Client Access server.
– Select a virtual directory and then, in the virtual directory details pane, verify that the External URL field is populated with the correct FQDN and service as shown below:

Virtual directory External URL value
Autodiscover No external URL displayed

To verify that you have successfully configured DNS, do the following:

– Open a command prompt and run nslookup.exe.
– In nslookup, look up the A record of each FQDN you created. Verify that the IP address that’s returned for each FQDN is correct.
– In nslookup, type set type=mx and then look up the accepted domain you added in Step
– Verify that the value returned matches the FQDN of the Client Access server.


So in this post, we’ve gotten past all the configuration steps to get Exchange 2013 up and running. We’ve configured Send and Receive connectors, as well as accepted email address policies. We configured a SSL Certificate to support client access via ActiveSync and OutlookAnywhere. Finally, we configured external DNS settings to enable Exchange to receive emails from the rest of the world.

In the next post, we will peer behind the hood of Exchange 2013 and learn a bit more abou the Mail Routing and Mail Flow behavior of Exchange as well as Exchange’s new Storage Engine.

Road Chimp, signing out.