Exchange 2007 and Exchange 2010

The Past: Exchange 2007 and Exchange 2010

In 2005, we set out developing Exchange 2007. During the preliminary planning of Exchange 2007, we realized that the server architecture model had to evolve to deal with hardware constraints, like CPU, that existed at the time and would exist for a good portion of the lifecycle of the product. The architectural change resulted in five server roles, three of which were core to the product:

Edge Transport for routing and anti-malware from the edge of the organization
Hub Transport for internal routing and policy enforcement
Mailbox for storage of data
Client Access for client connectivity and web services
Unified Messaging for voice mail and voice access

Figure 1: Server role architecture in Exchange 2007 & Exchange 2010

Our goal was to make these server roles autonomous units. Unfortunately, that goal did not materialize in either Exchange 2007 or Exchange 2010. The server roles were tightly coupled along four key dimensions:

Functionality was scattered across all the server roles, thereby making it a requirement that Hub Transport and the Client Access server roles be deployed in every Active Directory site where Mailbox servers were deployed.
This also necessitated a tight versioning alignment – a down-level Hub Transport or Client Access shouldn’t communicate with a higher version Mailbox server; in some cases this was enforced (e.g., Exchange 2007 Hub Transport servers cannot deliver messages to Exchange 2010 Mailbox servers), but in other cases they were not (e.g., an Exchange 2010 SP1 Client Access server can render data from an Exchange 2010 SP2 Mailbox server). The versioning restriction also meant that you could not simply upgrade a single server role to take advantage of new functionality – you had to upgrade all of them.
The server roles were also coupled together from a geographical affinity perspective as well due to the middle tier server roles using RPC as the communication mechanism to the Mailbox server role.
Similarly, from a user perspective, the server roles were also tightly coupled – a set of users that are served by a given Mailbox server, are always served by a given set of Client Access and Hub Transport servers.
The functionality and versioning aspects are the key issues. To understand it better, let’s look at the following diagram:

Figure 2: Inter-server communication across different layers of functionality

As you can see from the above diagram, there are three layers: 1) Protocols 2) Business Logic and 3) Storage. If you are familiar with the OSI model, you might believe the protocol layer is similar to the application layer and that data has to flow from the application layer through the other layers to get to the physical layer (or vice versa). However, that is not the case in Exchange 2007 or Exchange 2010; a protocol can interact directly with the storage layer. For example, the transport instance on Server1 (Exchange 2010 SP1) can deliver mail to the Store service on Server2 (Exchange 2010 SP2). The reverse is also true, the store can submit mail via the Store Submission service on Server2 to the transport service running on Server1. In either scenario, content conversion happens on the lower version server (as content conversion in this example happens within the transport components). While a newer version interacting with an older version may not be problematic, the same cannot be said when the reverse is true as the older version simply does not know about any changes that exist in the newer version that may break functionality (hence, why we put in blockers in certain circumstances, or provide guidance on upgrade procedures).

The end result is that in Exchange 2007 and Exchange 2010 deployments, the server roles are deployed as a single monolithic entity.

The Present: Exchange Server 2013

When we started our planning for Exchange Server 2013, we focused on a single architectural tenet – improve the architecture to serve the needs of deployments at all scales, from the small 100 user shop to hosting hundreds of millions of mailboxes in Office 365. This single tenet drove us to make major architectural changes and investments across the entire product. This shift is in part, because unlike when we were designing Exchange 2007, we are no longer CPU bound; in fact there is so much readily available CPU on modern server hardware, that the notion of dedicated server roles no longer makes sense as hardware ultimately is wasted (hence the recommendation in Exchange 2010 to deploy multi-role servers).

In Exchange Server 2013, we have two basic building blocks – the Client Access array and the Database Availability Group (DAG). Each provides a unit of high availability and fault tolerance that are decoupled from one another. Client Access servers make up the CAS array, while Mailbox servers comprise the DAG.

Figure 3: New server role architecture simplifies deployments

So what is the Client Access server in Exchange 2013? The Client Access server role is comprised of three components, client protocols, SMTP, and a UM Call Router. The CAS role is a thin, protocol session stateless server that is organized into a load balanced configuration. Unlike previous versions, session affinity is not required at the load balancer (but you still want a load balancer to handle connection management policies and health checking). This is because logic now exists in CAS to authenticate the request, and then route the request to the Mailbox server that hosts the active copy of the mailbox database.

The Mailbox server role now hosts all the components and/or protocols that process, render and store the data. No clients will ever connect directly to the Mailbox server role; all client connections are handled by the Client Access server role. Mailbox servers can be added to a Database Availability Group, thereby forming a high available unit that can be deployed in one or more datacenters.

Unlike the past two generations, these two server roles do not suffer from the same constraints:

Functionality is not dispersed across both server roles. All data rendering now occurs on the Mailbox server that hosts the active mailbox database copy. As we will discuss in more detail in a future article, the Client Access server role is merely a proxy.
Versioning is also decoupled as a result of moving the data rendering stack to a single server role.
Client Access servers and the Mailbox servers no longer leverage the chatty RPC protocol for client sessions, thereby removing the geographical affinity issues.
From a user perspective, users do not need to be serviced by the Client Access servers that are located within the same Active Directory site as the Mailbox servers hosting the user’s mailboxes.
If we return to the layering diagram, we can see how this changes:

Figure 4: Inter-server communication in Exchange 2013

Instead of allowing communication between servers to occur at any layer in the stack, communication must occur between servers at the protocol layer. This ensures that for a given mailbox’s connectivity, the protocol being used is always served by the protocol instance that is local to the active database copy. In other words, if my mailbox is located on Server1 and I want to send a message to a mailbox on Server2, the message must be sent from Server1’s transport components to the transport components on Server2; content conversion of the message then occurs on Server2 as the message is injected into the store. If I upgrade the Mailbox server with a service pack or cumulative update, then for a given mailbox hosted on that server, all data rendering and content conversions for that mailbox will be local, thus removing version constraints and functionality issues that arose in previous releases.

Looking Ahead

This article is the start of several articles focused on architecture and the investments we have made in Exchange Server 2013. Over the next several weeks:

We will delve into more specifics with respect to the server roles.
Discuss our investments with respect to storage.
Discuss sizing Exchange Server 2013.
Discuss load balancing and namespace planning.
And for those of you that did not get a chance to attend MEC 2012, feel free to visit and watch my technical architecture keynote.


Exchange Server 2013 introduces a new building block architecture that facilitate deployments at all scales. All core Exchange functionality for a given mailbox is always served by the Mailbox server where the mailbox’s database is currently activated. The introduction of the Client Access server role changes enables you to move away from complicated session affinity load balancing solutions, simplifying the network stack. From an upgrade perspective, all components on a given server are upgraded together, thereby virtually eliminating the need to juggle Client Access and Mailbox server versions. And finally, the new server role architecture aligns Exchange with being able to take advantage of hardware trends for the foreseeable future – core count will continue to increase, disk capacity will continue to increase, and RAM prices will continue to drop.

Posted in Uncategorized | Leave a comment

Exchange Server 2013 Gotchas

Exchange Server 2013 Gotchas

Exchange Server 2013 reached RTM a couple of months ago and has since reached General Availability (GA).

In my personal opinion, Exchange 2013 RTM is not ready for prime time. Microsoft made a decision to release all of Wave 15 (Office desktop applications and servers) at the same time; as well as release Windows 8, Windows RT, and Windows Server 2012 at the same time. I think this decision was seriously flawed. It is obvious that the products were not complete at RTM (witness Windows 2012 and Windows 8 having 300 MB of patches between RTM and GA, and Exchange 2013 not supporting any interop with prior versions of Exchange at either RTM or GA). It is easy to conclude that the RTM dates were artificially imposed.

I have prepared a class on Exchange 2013 for one of my clients and part of that class was to discuss the limitations associated with Exchange 2013 RTM when compared to Exchange 2010 SP2. Note that the rest of the class discussed many of the new features and capabilities that have been added to Exchange 2013. So… the story is not all bad.

But as a summary of my opinion, Exchange 2013 RTM is not ready for prime time. Right now, it can only be installed in a green-field environment (that is, an environment where Exchange did not previously exist), so it is a safe bet that the Exchange team agrees with that as well. We can hope that some updates will quickly come out to address some of the current deficiencies.

This list is by no means exhaustive. And, as always, whether a particular issue is important to your organization requires you to evaluate your environment.


  • Help -> About is gone
  • It’s very slow.
  • No S/MIME support
  • No Public Folder support, either for legacy public folders or modern public folders.
  • No distribution list moderation
  • No way to move the reading pane
  • Built-in spell-check is gone. IE 10 provides spell-check natively, but earlier versions of IE do not. A third-party add-in or an alternate browser is required.
  • Other things are gone; don’t waste too much time looking for them.

Client Connectivity

  • No BES support
  • …on a related note (and likely the primary reason BES is not yet available), the CDO/MAPI download is not yet available for Exchange 2013.
  • Outlook 2003 is no longer supported.
  • Direct MAPI access to the Exchange server is no longer supported.  RPC/HTTP (Outlook Anywhere) is required.
  • Outlook now reports that the server is it connected to is <<guid>>@<<active-directory-domain>>. This is intentional, if misguided.

Installation and Architecture

  • Cannot uninstall individual roles from a server, must uninstall all of Exchange
  • Install is painfully slow
  • The Hub Transport role is gone. There is now a Front End Transport service on CAS servers and Mailbox Transport services on Mailbox servers.
  • The Unified Messaging role is gone. There is a now a Unified Messaging Call Router service on CAS servers and a Unified Messaging service on Mailbox servers.
  • The CAS consists of three pieces: CAFE’ (Client Access Front End), which proxies all end-user protocols to the appropriate mailbox server (completing the decoupling of the MAPI endpoint started in Exchange 2010) and handles Outlook Web App; FET (Front End Transport) which proxies SMTP protocols to the mailbox server and is responsible for TLS setup; and Unified Messaging Call Router.
  • After an installation or an upgrade, services not starting is an endemic problem. You will likely need to increase ServicesPipeTimeout on your Exchange servers.
  • Documentation is minimal at best
  • Deployment and sizing guidance is non-existent.
  • Cannot be installed along with Exchange 2007 or Exchange 2010
  • Exchange 2013 Edge server is not available
  • Forefront Protection for Exchange is gone
  • For both Exchange 2010 and Exchange 2013, applying updates can often screw up the winrm configuration. If you get errors in EMS or EAC regarding “The WS-Management service cannot process the request”, try this first:

    winrm quickconfig

  • Since you cannot interop with legacy public folders in RTM, if you need an Organizational Forms Library, you must create it yourself. To create an Organizational Forms Library:

    1. Create “Organizational Forms Library” folder under the Eforms Registry:

    New-publicfolder “Organizational Forms Library” -path “\non_ipm_subtree\Eforms Registry”

    2. Set the locale ID for the Org Forms Library:

    Set-PublicFolder “\non_ipm_subtree\Eforms Registry\Organizational Forms Library” -EformsLocaleID EN-US

    It is no longer necessary to set the PR_URL_NAME property.

Exchange Management

  • The Exchange Management Console is gone as is the Exchange Control Panel. They are mainly replaced by the Exchange Administration Center (EAC); which is completely web based.
  • If you are attempting to use EAC with IE 10, you need KB2761465 (released on December 11, 2012).
  • The Exchange Best Practices analyzer is no more.
  • The Exchange Mail Flow Troubleshooter is no more.
  • The Exchange Performance Troubleshooter is no more.
  • The Exchange Routing Log Viewer is no more.
  • The EAC does not provide a preview (or an after-view for that matter) of the PowerShell it executed.
  • Antispam and antimalware is crippled compared to earlier releases

    The E15 AV does not offer a quarantine
    The E15 AS does offer a quarantine (for the administrator, not per-user)

  • Antispam cannot be managed from the Exchange Administration Center; it must be managed using PowerShell in the Exchange Management Shell
  • Kerberos Constrained Delegation (KCD) is not supported for OWA
  • This isn’t new, but should be reinforced: DO NOT TURN OFF IPV6. Microsoft does not perform any testing to determine the effects of disabling IPv6. Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled. See
  • System Center Data Protection Manager (DPM) version required for backups of Exchange 2013 is SC DPM 2012 SP1

Mailboxes and Databases

  • Mailbox sizes MAY appear to increase substantially when moving a mailbox to an Exchange 2013 mailbox server. In Exchange 2010 and before, only select properties of a particular mailbox item were assigned as part of the mailboxes diskspace allocation, causing under-reporting. Now, all item properties for a particular mailbox item are assigned to the mailboxes disk space allocation. However, some items in Exchange 2013 are now compressed which were not before. This can lead to a reduction in reported and allocated diskspace. So, prediction is basically impossible. Just be aware that it may happen.
  • Corrupt PropertyTags during a mailbox move are common. Using (Get-MoveRequestStatistics -IncludeReport <<alias-name>>).Report.Failures you can find the rule or message that is causing the problem and remove it.
  • Changes made to improve Office 365 and hybrid deployments had an unintended consequence (this is my conclusion). When you are performing impersonation (e.g., to open a different user’s mailbox via EWS), you should always impersonate using the email address.
  • As a corollary, it is recommended that the account UPN match the primary email address.
  • In a change that you won’t know about until you need to know it – MRS Proxy is not enabled by default in Exchange 2013. Use Set-WebServicesVirtualDirectory to enable it.
  • Clean-MailboxDatabase is gone

    Update-StoreMailboxState is designed to replace it
    Requires that you know the guid of the deleted mailbox
    No on-premises cmdlets allow you to find those out!

  • Get-LogonStatistics is non-operational. The cmdlet is still present, but it doesn’t work.
  • Exchange 2013 Enterprise Edition supports only 50 mailbox databases instead of the 100 supported in Exchange 2010
  • MRM 1.0 (Messaging Record Management – Managed Folders) is non-operational on Exchange 2013 mailbox servers. The cmdlets are still present, and will affect down-level servers (which you can’t use right now), but they don’t work with Exchange 2013 servers.
  • Moving mailboxes using the migration wizard in EAC can generate large amounts of log files for the database which hosts the arbitration mailbox. Use New-MoveRequest instead.
  • In a positive change, Office Filter Packs are no longer required. There is a new search technology used in all Wave 15 (Office 2013) products and it knows how to search all the Office file formats. This also includes the PDF format, so a separate iFilter installation for PDF is no longer required.
  • When using Database Availability Groups (DAGs) on Windows Server 2012, you must manually create the Cluster Network Object (CNO) and provision the CNO by assigning permissions to it.
  • While Windows Server 2012 provides support for large sectors (4 KB), Exchange 2013 does not support large sectors. Emulation of large sectors (512 E) is supported provided that all database copies are on 512 E.
  • The above statement is, in general, true. Additional capabilities of Windows Server 2012 are not supported by Exchange Server 2013. This specifically includes but is not limited to Hyper-V Replica.
Posted in Uncategorized | Leave a comment

Exchange 2013 System mailboxes

Exchange 2013 System mailboxes


System mailboxes are created by Exchange in the root domain of the Active Directory forest during installation. Users or administrators can’t sign in to these mailboxes. System mailboxes are created for Exchange features such as Unified Messaging (UM), migration, message approval, and In-Place eDiscovery. This table lists information about system mailboxes as they’re displayed in Active Directory.

Organization Mailbox

SystemMailbox {bb558c35-97f1-4cb9-8ff7-d53741dc928c}

Message approval Mailbox

SystemMailbox {1f05a927-xxxx- xxxx – xxxx -xxxxxxxxxxxx}

where x is a randomly assigned and unique number for each Exchange forest

UM data storage Mailbox

SystemMailbox {e0dc1c29-89c3-4034-b678-e6c29d823ed9}

Discovery Mailbox

DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}

Federated email Mailbox


Migration Mailbox 


If you want to decommission the last Mailbox server in your Exchange organization, you should first disable these system mailboxes by using the Disable-Mailbox cmdlet. When you decommission a Mailbox server that contains these system mailboxes, you should move the system mailboxes to another Mailbox server to make sure that you don’t lose functionality.

Posted in Uncategorized | Leave a comment


is a feature for quickly restoring database redundancy after a disk failure. If a disk fails, the database copies stored on that disk are automatically reseeded to a preconfigured spare disk on the Mailbox server. You can use the steps in this topic to configure AutoReseed for a database availability group (DAG).

Posted in Uncategorized | Leave a comment