Exchange Server 2016 Architecture

Exchange Server 2016 builds upon the architecture introduced in Exchange Server 2013, with the continued focus goal of improving the architecture to serve the needs of deployments at all scales.

Important: This article contains preliminary information that may be changed prior to final commercial release of the software described herein.

Building Block Architecture

In Exchange Server 2016, there is a single building block that provides the client access services and the high availability architecture necessary for any enterprise messaging environment.


Figure 1: Building Block Architecture

In our continuing quest to improve the product’s capabilities and simplify the architecture and its deployment, we have removed the Client Access server (CAS) role and added the client access services to the Mailbox role. Even without the CAS role, the system maintains loose coupling in terms of functionality, versioning, user partitioning and geographical affinity.

The Mailbox server role now:

  1. Houses the logic to route protocol requests to the correct destination endpoint.
  2. Hosts all of the components and/or protocols that process, render and store the data.

No clients connect directly to the back-end endpoints on the Mailbox server; instead, clients connect client access services and are routed (via local or remote proxy) to the Mailbox server that hosts the active database that contains the user’s mailbox.

Mailbox servers can be added to a Database Availability Group (DAG), thereby forming a high availability unit that can be deployed in one or more datacenters. DAGs in Exchange Server 2016 do have a few specific enhancements:

  1. DatabaseAvailabilityGroupIpAddresses is no longer required when creating a DAG. By default, the failover cluster will be created without an administrative access point, as this is the recommended best practice.
  2. Replay Lag Manager is enabled by default.
  3. Lagged database copy play down can be delayed based on disk latency, thereby ensuring active users are not impacted.
  4. Database failovers times are reduced by 33% when compared to Exchange Server 2013.

Removal of the separate CAS role does not affect how communication occurs between servers. Communication between servers still occurs at the protocol layer, effectively ensuring that every server is an island. 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.


Figure 2: Inter-server communication in Exchange 2016

The load balancer configuration is also not affected by this architectural change. From a protocol perspective, the following will happen:

  1. A client resolves the namespace to a load balanced virtual IP address.
  2. The load balancer assigns the session to a Mailbox server in the load balanced pool.
  3. The Mailbox server authenticates the request and performs a service discovery by accessing Active Directory to retrieve the following information:
    1. Mailbox version (for this discussion, we will assume an Exchange 2016 mailbox)
    2. Mailbox location information (e.g., database information, ExternalURL values, etc.)
  4. The Mailbox server makes the decision to proxy the request or redirect the request to another Mailbox server in the infrastructure (within the same forest).
  5. The Mailbox server queries an Active Manager instance that is responsible for the database to determine which Mailbox server is hosting the active copy.
  6. The Mailbox server proxies the request to the Mailbox server hosting the active copy.

The protocol used in step 6 depends on the protocol used to connect to client access services. If the client request uses HTTP, then the protocol used between the servers is HTTP (secured via SSL using a self-signed certificate). If the protocol used by the client is IMAP or POP, then the protocol used between the servers is IMAP or POP.

Telephony requests are unique. Instead of proxying the request at step 6, the Mailbox server will redirect the request to the Mailbox server hosting the active copy of the user’s database, as the telephony devices support redirection and need to establish their SIP and RTP sessions directly with the Unified Messaging services on the Mailbox server.


Figure 3: Client Protocol Connectivity

And yes, the Edge Transport server role will ship in Exchange Server 2016 (and at RTM, to boot!). All the capabilities and features you had in the Edge Transport server role in Exchange Server 2013, remain in Exchange Server 2016.

Why did we remove the Client Access server role?

The Exchange Server 2016 architecture evolves the building block architecture that has been refined over the course of the last several releases. With this architecture, all servers in the Exchange environment (excluding Edge Transport) are exactly the same—the same hardware, the same configuration, and so forth. This uniformity simplifies ordering the hardware, as well as performing maintenance and management of the servers.

As with Exchange 2010 and in Exchange 2013, we continue to recommend role co-location as a best practice. From a cost perspective, the overall goal is to ensure that the architecture is balanced for CPU and disk. Having separate server roles can result in long-term cost disadvantages as you may purchase more CPU, disk, and memory resources than you will actually use. For example, consider a server that hosts only the Client Access server role. Many servers enable you to add a given number of disks in a very economical fashion—when you are deploying and using that number of disks, the cost is essentially zero. But if you deploy a server role that uses far less than the given number of disks, you’re paying for a disk controller that is either under-used or not used at all.

This architecture is designed to enable you to have fewer physical Exchange servers in your environment. Fewer physical servers mean lower costs for a variety of reasons:

  • Operational costs are almost always higher than the capital costs. It costs more to manage a server over its lifetime than it does to purchase it.
  • You purchase fewer Exchange server licenses. This architecture only requires a license for one Exchange server and one operating system, while breaking out the roles required multiple Exchange server licenses and multiple operating system licenses.
  • Deploying fewer servers has a trickle-down effect across the rest of the infrastructure. For example, deploying fewer physical servers may reduce the total rack and floor space required for the Exchange infrastructure, which in turn reduces power and cooling costs.

This architecture ultimately distributes the load across a greater number of servers than deploying single-role servers because all Mailbox servers also handle client access because:

  • You’re distributing the load across a greater number of physical machines, which increases scalability. During a failure event, the load on the remaining servers only increases incrementally, which ensures the other functions the server is performing aren’t adversely affected.
  • The solution can survive a greater number of Client Access role (or service) failures and still provide service, which increases resiliency.

Key Architectural Improvements

Exchange Server 2016 also includes a number of architectural improvements, beyond the server role consolidation, including search enhancements, document collaboration improvements, and more.

Search Improvements

One of the challenging areas for on-premises environment was the amount of data that was replicated with each database copy in previous releases. In Exchange Server 2016, we have reduced bandwidth requirements between the active copy and a passive copy by 40%. This was accomplished by enabling the local search instance to read data from its local database copy. As a result of this change, passive search instances no longer need to coordinate with their active counterparts in order to perform index updates.

Another area of investment in search has been around decreasing the length of time to return search results, especially in online mode clients like OWA. This is accomplished by performing multiple asynchronous disk reads prior to the user completing the search term, which populates the cache with the relevant information, providing sub-second search query latency for online mode clients.

Document Collaboration

In previous releases of Exchange, OWA included document preview for Office and PDF documents, reducing the need to have a full fidelity client. SharePoint had a similar feature, however it used the Office Web Apps Server to accomplish this capability. Within Office 365, we also leverage Office Web Apps Server to provide this capability, ensuring uniform document preview and editing capability across the suite.

In Exchange Server 2016, we leverage Office Web Apps Server to provide the rich document preview and editing capabilities for OWA. While this was a necessary change to ensure a homogenous experience across the Office Server suite, this does introduce additional complexity for environments that don’t have Office Web Apps Server.

The next generation of Office Web Apps Server will not be supported for co-location with Exchange. Therefore, you must deploy a separate server farm infrastructure. This infrastructure will require unique namespaces, and will require session affinity to be maintained at the load balancer.

While Exchange supports an unbound namespace model, the Office Web Apps Server will require a bound namespace for each site resilient datacenter pair. However, unlike the bound namespace model within Exchange, Office Web Apps Server will not require any namespace changes during a datacenter activation.



Figure 4: Office Web Apps Server Connectivity


Office 365 introduced the REST APIs (Mail, Calendar, and ContactAPIs), and now these APIs are available in Exchange Server 2016. The REST APIs simplify programming against Exchange by providing a familiar syntax that is designed with openness (e.g., open standards support JSON, OAUTH, ODATA) and flexibility (e.g., granular, tightly scoped permission to access user data). These APIs allow developers to connect from any platform, whether it be web, PC, or mobile. SDKs exist for.NET, iOS, Android, NodeJS, Ruby, Python, Cordova, and CORS for use in single page JavaScript web apps.

What about Exchange Web Services (EWS)? All existing applications that leverage EWS will continue to work with Exchange Server 2016. We are, however, focusing new platform investments on the REST APIs and the apps for Office extensibility model. We expect to make significantly fewer investments in EWS so that we can focus our resources on investing in a single modern API that will, over time, enable most of the scenarios that our partners currently use EWS.

Outlook Connectivity

Introduced in Exchange Server 2013 Service Pack 1, MAPI/HTTP is the new standard in connectivity for Outlook. In Exchange Server 2016, MAPI/HTTP is enabled by default. In addition, Exchange Server 2016 introduces per-user control over this connectivity model, as well as, the ability to control whether the protocol (and Outlook Anywhere) is advertised to external clients.

Note: Exchange Server 2016 does not support connectivity via the MAPI/CDO library. Third-party products (and custom in-house developed solutions) need to move to Exchange Web Services (EWS) or the REST APIs to access Exchange data.

Coexistence with Exchange Server 2013

In Exchange Server 2013, the Client Access server role is simply an intelligent proxy that performs no processing/rendering of the content. That architectural tenet paid off in terms of forward coexistence. When you introduce Exchange Server 2016, you do not need to move the namespace. That’s right, the Exchange Server 2013 Client Access infrastructure can proxy the mailbox requests to the Exchange 2016 servers hosting the active database copy! For the first time ever, you get to decide when you move the namespace over to the new version. And not only that, you can even have load balancer pools contain a mix of Exchange Server 2013 and Exchange Server 2016. This means you can do a one-for-one swap in the load balancer pool – as you add Exchange 2016 servers, you can remove Exchange 2013 servers.

Topology Requirements

Exchange Server 2016 will only be supported on Windows Server 2012, Windows Server 2012 R2 and Windows Server “10” operating systems.

From an Active Directory perspective, Exchange Server 2016 will require:

  • Windows Server 2008 or later Active Directory servers.
  • Windows Server 2008 or higher Forest Functional Mode and Domain Functional Mode.

Exchange Server 2016 will only support coexistence with Exchange Server 2010 SP3 RU11* and Exchange Server 2013 CU11* (*subject to change).

The Preferred Architecture

During my session at Microsoft Ignite, I revealed Microsoft’s preferred architecture (PA) for Exchange Server 2016. The PA is the Exchange Engineering Team’s best practice recommendation for what we believe is the optimum deployment architecture for Exchange 2016, and one that is very similar to what we deploy in Office 365.

While Exchange 2016 offers a wide variety of architectural choices for on-premises deployments, this architecture is our most scrutinized one ever. While there are other supported deployment architectures, they are not recommended.

The Exchange 2016 PA is very similar to the Exchange 2013 PA. A symmetrical DAG is deployed across a datacenter pair with active database copies distributed across all physical servers in the DAG. Database copies are deployed on JBOD storage, with four copies per-disk. One of the copies is a lagged database copy. Clients connect to a unified namespace that is equally distributed across the datacenters in the site resilient pair.

However, the Exchange 2016 PA differs in the following ways:

  1. Exchange’s unbound namespace model is load balanced across the datacenters in a layer 7 configuration that does not leverage session affinity.
  2. An Office Web Apps Server farm is deployed in each datacenter, with each farm having a unique namespace (bound model). Session affinity is managed by the load balancer.
  3. The DAG is deployed without an administrative access point.
  4. The commodity dual-socket server hardware platform contains 20-24 cores and up to 196GB of memory, and a battery-backed write cache controller.
  5. All data volumes are formatted with ReFS.

As we get closer to release, we’ll publish a complete Exchange 2016 Preferred Architecture article.


Exchange Server 2016 continues in the investments introduced in previous versions of Exchange by reducing the server role architecture complexity, aligning with the Preferred Architecture and Office 365 design principles, and improving coexistence with Exchange Server 2013.

These changes simplify your Exchange deployment, without decreasing the availability or the resiliency of the deployment. And in some scenarios, when compared to previous generations, the PA increases availability and resiliency of your deployment.

Event ID 9373 is logged in the Application log when you update the offline address book in Exchange Server

When you update the offline address book by using the Update-OfflineAddressBook command or by using a scheduled task, the following event (Event ID 9373) is logged in the Application log on a computer that is running Microsoft Exchange Server 2007:
Event Type: Error
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9373
Description: OALGen detected that the file ‘\\\ExchangeOAB\\a58e388b-7b23-4944-b042-58a7d0c6590f-data-1.lzx’ is corrupted or missing. This indicates data tampering or disk problems. Restore files in this folder from the recent backup or clean up folder content and force a full OAB generation. – Default Offline Address Book

This issue occurs when one or more OAB Version 4 offline address book files are corrupted or missing. In this case, the Microsoft Outlook clients cannot download the updated files until the issue is resolved.

To resolve this issue, use one of the following methods.
Method 1: Restore the contents of the OABGen folder

If daily backups are available, restore the contents of the OABGen folder to the following folder:
ExchangeInstallDir\ExchangeOAB\OAB GUID
Note ExchangeInstallDir is a placeholder for the name of the Exchange Server 2007 installation directory. OAB GUID is a placeholder for the name of the folder.
Method 2: Rebuild the offline address book files by using Exchange Management Console or the Exchange Management Shell

If the corrupted offline address book item is enabled for public folders distribution, and if the data was published in public folders before the offline address book item was corrupted, delete the contents of the OABGen folder from the ExchangeInstallDir\ExchangeOAB\OAB GUID folder. Then, rebuild the offline address book files by using one of the following methods:
Use Exchange Management Console to rebuild the offline address book files. To do this, follow these steps:
Open Exchange Management Console.
Expand Organization Configuration, and then expand Mailbox.
On the details panel, click Offline Address Book, and then select the offline address book item that you want to update.
On the Action panel, click Update, and then click Yes.
Use the Update-OfflineAddressBook command to rebuild the offline address book files.

To do this, run the following command in the Exchange Management Shell.
Note You can run the Update-OfflineAddressBook command on a computer that has the Mailbox, Client Access, or Hub Transport server role installed. To do this, you must log on by using an account that is a member of the Exchange Organization Administrators group. The account must also be a member of the local Administrators group on that computer.
Method 3: Rebuild the offline address book files by using a command

If neither daily backups nor public folders distribution is available, delete the contents of the OABGen folder from the ExchangeInstallDir\ExchangeOAB\OAB GUID folder. Then, rebuild the offline address book files by using one of the following commands.
Update-OfflineAddressBook -Identity MyOAB
Note In this example, the Update-OfflineAddressBook command is used to update the offline address book file that is named MyOAB.
Note When you use this command, the offline address book will be rebuilt. This will cause all clients to process a full offline address book download. For OAB Version 2 and OAB Version 3a, a full offline address book download can cause massive network traffic between client access servers and clients.

Configure Outlook 2007 to work over HTTP using RPC protocol

To setup RPC over HTTP on windows XP using Outlook 2007 click on Start and then click on Control Panel then click on the Mail applet in control panel.

The mail setup window should show up:


Click on E-mail Accounts..Then click on Account Settings, click on New:


  1. The new E-mail Account Setup should come up. Select Microsoft Exchange, POP3, IMAP, or HTTP and click Next


Click on “Manually configure server settings or additional server type. then click Next:

Select Microsoft Exchange on the next screen. Click Next. On the next screen, enter the name of the exchange server, and the Username:


After you have entered the info, click on More Settings. Click on the Connection tab on the Microsoft Exchange window:


Check the dial box to connect to Microsoft Exchange using HTTP and then click on Exchange Proxy Settings.

The Microsoft Exchange Proxy Settings windows should come up:


Check Connect Using SSL only if your organization exchange server is configured for SSL socket using the 443 port. Otherwise uncheck it. Enter the information about your exchange server as the screen shot below:


After you have entered all the information, close out of all the windows, and restart Outlook 2007. Your Outlook 2007 should work from anywhere now.

How to setup a Blackberry Support user account

1. Login to BES console.

2. Expand Administrator users

3. Click Create an administrator user

4. Fill in the required fields: only use ADM accounts for Admin logins.

5. For Role: Select Senior helpdesk Administrator. Do not create an Enterprise admin account.

6. clip_image002

7. Enter your password in the Administrators password field.

8. Click > Create an administrator user.

9. Done.

Non Delivery Report (NDR) Error Codes For MS Exchange Server 2007


Below are the NDR codes for MS Exchange 2007. Knowledge of Non Delivery Report (NDR) Codes and their relative meanings help to resolve the Email Delivery Issues very fast and accurately.

NDR Codes

Explanation of Codes in Exchange Server 2007
4.2.2 The recipient has exceeded their mailbox limit. It could also be that the delivery directory on the Virtual server has exceeded its limit.
4.3.1 Insufficient system resources.  This normally means not enough disk space on the delivery server. Microsoft say this Exchange NDR may be reported as out-of-memory error.
4.3.2 A classic temporary problem.  Most likely, the Administrator has frozen the queue.
4.4.1 Intermittent network connection.  The server has not yet responded.  Classic time-out problem.  If it persists, you will also get a 5.4.x status code error.
4.4.2 The server started to deliver the message but then the connection was dropped.  The sending server is configured to retry automatically.
4.4.6 Too many hops.  Most likely, the message is looping.
4.4.7 Problem with a protocol timeout, for example a message header limit.  Check receiving server connectors.
4.4.9 A DNS problem.  Check your smart host setting on the SMTP connector.  For example, check correct SMTP format. Also, use square brackets in the IP address []  You can get this same NDR error if you have been deleting routing groups.
4.6.5 Multi-language situation.  Your server does not have the correct language code page installed.
5.0.0 SMTP 500 reply code means an unrecognized address.  You get this NDR when you make a typing mistake when you manually try to send email via telnet. The most likely cause is a routing error.  One solution maybe to add an * in the address space. A separate cause for NDR 5.0.0 is a DNS problem.
5.1.x Exchange 2007 NDR problems with email address.
5.1.0 Sender denied.  Often seen with contacts. Verify the recipient address. Mismatched Network Card duplex setting.
5.1.1 Bad destination mailbox address.  5.1.1 is the most common Exchange 2007 NDR; there is a problem with the recipient address. Maybe the recipient does not exist. Possibly the user was moved to another server in Active Directory. Check mailbox delegation. Maybe an Outlook client replied to a message while offline. Check connector configuration.
5.1.2 SMTP; 550 Host unknown.  An error is triggered when the host name can’t be found.  For example, when trying to send an email to bob@ [Example kindly sent in by Paul T.]
5.1.3 Invalid recipient address.  Another problem often seen with contacts.  Address field maybe empty.  Check the address information.  Or there could be a syntax error.
5.1.4 Destination mailbox address ambiguous.  Two objects have the same address, which confuses the Exchange 2007 Categorizer.
5.1.5 Destination mailbox address invalid.
5.1.6 Problem with homeMDB or msExchHomeServerName – check how many users are affected.  Sometimes running RUS (Recipient Update Service) cures this problem.  Mailbox may have moved.
5.1.7 Invalid address.  Problem with senders mail attribute, check properties sheet in ADUC.
5.1.8 Something the matter with sender’s address
5.2.x NDR caused by the large size of the email.
5.2.1 Mailbox cannot be accessed.
5.2.2 The recipient has exceeded their mailbox storage quota.
5.2.3 Recipient cannot receive messages this big.
5.2.4 Most likely, a distribution list or group is trying to send an email.
5.3.0 Problem with MTA, maybe someone has been editing the registry to disable the MTA.
5.3.1 Mail Server system full.
5.3.2 System not accepting outside network messages.
5.3.3 Remote server has insufficient disk space to hold email.
5.3.4 Message too big.
5.3.5 System incorrectly configured.  Multiple Virtual Servers are using the same IP address and port.
5.4.0 DNS Problem.
5.4.1 No answer from host.
5.4.2 Bad connection.
5.4.3 Routing server failure.  No available route.
5.4.4 Cannot find the next hop, check the Routing Group Connector.
5.4.6 Tricky looping problem, a contact has the same email address as an Active Directory user.
5.4.7 Delivery time-out.  Message is taking too long to be delivered.
5.4.8 Microsoft advises, check your recipient policy. SMTP address should be NOT
5.5.0 Underlying SMTP 500 error.  Our server tried ehlo, the recipient’s server did not understand and returned a 550 or 500 error.
5.5.1 Invalid command.  (Rare Exchange NDR)
5.5.2 Possibly the disk holding the operating system is full.
5.5.3 Too many recipients.  More than 5,000 recipients.
5.5.4 Invalid domain name.
5.5.5 Wrong protocol version.
5.5.6 Invalid message content.
5.6.0 Corrupt message content.  Try sending without attachment.
5.6.1 Media not supported.
5.6.3 More than 250 attachments.
5.7.1 A very common Exchange 2007 NDR, the cause is a permissions problem.  For some reason the sender is not allowed to email this account. Perhaps an anonymous user is trying to send mail to a distribution list. Alternatively, a user may have a manually created email address that does not match a System Policy. Check SMTP Virtual Server Access Tab.  Try checking this box: Allow computers which successfully authenticate to relay. Check the outgoing SMTP logs. Check: Mailbox – <Mailboxname> – Properties – Mail Flow Settings – Message delivery restrictions. Try disabling Windows-Integrated-Security.  Instead allow only standard authorization on the SMTP receiver on the Exchange 2007 server. Check Attachment filtering on the Edge server.
5.7.2 Distribution list cannot expand and so is unable to deliver its messages.
5.7.3 Not Authorized, security problem.  It could be that the sender cannot send to the alternative address. On another tack, check external IP address of ISA server. Make sure it matches the SMTP publishing rule.
5.7.4 Extra security features not supported.  Check delivery server settings
5.7.5 Cryptographic failure.  Try a plain message with encryption.
5.7.6 Certificate problem, encryption level maybe to high.
5.7.7 Message integrity problem.

Event ID 9877 with error code “0x80041606” when you use Outlook in online mode to search for a keyword in Exchange Server 2010

Event Log Details:-

Log Name: Application
Source: MSExchangeIS Mailbox Store
Date: Date
Event ID: 9877
Task Category: Content Indexing
Level: Error
Keywords: Classic
User: N/A
Computer: Computer
Content Indexing function ‘CISearch::EcGetRowsetAndAccessor’ received an unusual and unexpected

error code from MSSearch.

Mailbox Database: Mailbox Database
Error Code: 0x80041606

Cause Of Issue:-

This issue occurs because Exchange Search has a hard-coded prefix search limit of

200,000 nodes for a single character search. When a prefix search exceeds this limit, the search returns QUERY_E_TOOCOMPLEX. Therefore, 0x80041606 is logged

as part of event ID 9877. By default, all searches that use Outlook online mode

in an Exchange 2010 environment are prefix searches. Using single digits or

letters causes the system to search for all numbers or words that begins with the

single digit or letter across the whole mailbox database. If the 200,000 nodes

default limit is reached, the search returns the error.

Note The most common way to reach the 200,000 nodes limit is to search for

a word or phrase that contains a single digit or letter. There are also other less

common causes, such as entering very complex searches with many ANDs,

Ors, and NOTs. Additionally, complex combinations of date ranges and

search terms, many entries in the To and From fields, or a combination of all

these things may cause the limit to be reached.


Find More Details on link Below:-

MS Exchange 2010 Installation and Configuration


Starting with Exchange Server 2007 all SMTP traffic in Exchange Server is routed through the Hub Transport Server. The reason behind this is ‘compliancy’. By routing all messages through the Hub Transport Server it is always possible to track messages. It is also possible to temporarily store these messages so when a disaster strikes Exchange can always (try to) recover these messages from the Hub Transport Server such as, during a failover in a CCR cluster or a Database Availability Group. In this series of articles I’d like to explain a bit more about the Hub Transport Server and the SMTP message flow within Exchange Server 2010.

Message flow

In Exchange Server 2010 all messages are always routed through the Hub Transport Server. This is the case for:

  • Messages routed to and from the Internet, with and without an Edge Transport Server;
  • Messages routed to other Active Directory sites within the Exchange organization;
  • Messages between mailboxes on the same Mailbox Server, even mailboxes within the same Mailbox Database;

Yes, you read that last one correct. If there’s one Exchange 2010 Mailbox Server with only two mailboxes on it, and the first mailbox sends a message to the second mailbox, it is routed through the Hub Transport Server.

If the Hub Transport Server is not available, the message will not be sent and the message will not leave the mailbox!

Transport internals

To get a better idea of the message transport in Exchange Server 2010 we have to identify several services in the Exchange environment that play an important role in message routing.

  1. Mail Submission Service – when a message is created and the Send button is clicked, the new message is placed in the mailbox outbox. There’s a service running on the Mailbox Server role called the “Exchange Mail Submission Service” which notifies the Hub Transport Server that a new message is awaiting for processing. The Mailbox Server has an internal list of Hub Transport Servers in the same Active Directory site (the submission server list)

    which is updated every 10 minutes. This is done by the server discovery process. A round robin mechanism is responsible for load balancing the SMTP traffic across these Hub Transport Servers;
  2. Store Drivers – the Hub Transport Server’s Store Driver retrieves the message from the Outbox and puts it in the Submission Queue on the Hub Transport Server. The Store Driver uses RPC to retrieve the message from the Mailbox Server. There’s no traffic on port 25 (i.e. SMTP) between the Hub Transport Server and the Mailbox Server;
  3. Submission Queue – this is a queue, located on the Hub Transport Server where all messages are stored that need to be processed. Not only the Store drivers can store messages in the submission queue, but this can also be done through a receive connector or the pickup directory.
  4. Categorizer – the categorizer retrieves messages from the submission queue and determines where the message needs to be sent to. This can be an internal Active Directory recipient or an external recipient. The categorizer also expands distribution groups and identifies alternative recipients or forwarding addresses.
  5. Pickup Directory – this is a directory that is checked once every 5 seconds for new messages. When a message is in the correct EML format it is picked up from this directory and when the process is completed the file is deleted from the pickup directory.

Figure 1: Overview of the Hub Transport Server Role


A queue is a temporary location where messages that are waiting for processing are stored. The submission queue is already discussed, but there are more queues:

  • Mailbox Delivery Queue – This queue stores messages that will be delivered to mailboxes on a Mailbox Server. Again, communication between the Hub Transport Server and the Mailbox Server for mailbox delivery is encrypted RPC. Note: a mailbox delivery queue only exists on Hub Transport Servers and not on Edge Transport Servers;
  • Remote Delivery Queue – this is a queue where messages are stores that need to be delivered remotely.  Remote delivery queues can exists on Hub Transport Servers as well as Edge Transport Servers. There’s a remote delivery queue for every domain the Transport Server is sending messages to. So, if there are outbound messages sent to for example, then a remote delivery queue exists for the domain These remote delivery queues only exist for a small amount of time. After successful delivering of the message to, the queue for this domain is deleted, but only when no other messages are sent within a couple of minutes. Besides a remote delivery queue for every external domain, there’s also a remote delivery queue for every Active Directory site that contains other Hub Transport Servers;
  • Poison Message Queue – There are specific messages that Exchange considers to be harmful to the Exchange system after a server failure. If such messages are encountered then they are stored in the poison message queue. The poison message is empty during normal operations and therefore it does not appear in the Queue viewer.
  • Unreachable Queue – This queue contains messages that cannot be routed to their original destination, for example after reconfiguring the routing infrastructure.

Queue Database Files

In Exchange 2003 and earlier the queues were stored on the local disk in the c:mailrootqueue directory, or a queue directory in the Exchange Server directory. Exchange Server 2007 and Exchange Server 2010 store their queues in an ESE database. This database is located in the “C:Program FilesMicrosoftExchange ServerTransportRolesdataQueue” directory. ESE operations on this Queue Database file are similar to those of a normal ESE Mailbox Database file. So transactions are stored to the log files first and later on are committed to the Queue Database file. The checkpoint file keeps track of which transactions are already written to the Queue Database file.

Log files of the Queue Database file “circular logging” are enabled by default. This means that older log files are deleted when they are no longer needed. Because of this, it is not possible to recover old data from the log files. Since the data in the Queue Database file is volatile (i.e. it exists for a short period of time in the queue and the database) this is not an issue.

The Queue Database consists of the following files:

  • Mail.que – the actual Queue Database file;
  • Tmp.edb – temporary file for Queue Database file operations;
  • Trn*.log – the individual log files for storing Queue Database transactions;
  • Trn.chk – the checkpoint file that keeps track which transactions are already committed to the Queue Database;
  • Trnres00001.jrs and Trnres00002.jrs – two reserved empty log files that are used when the disk is full during normal log file operations.

Figure 2: The Queue directory on local disk. Already 2459 log files (99B hexadecimal) are createdon this server.




We have seen the message transport in Exchange and services that play an important role in message routing and went through the various queues of the Exchange database. In my next article I will cover the communication between Exchange Hub Transport Servers in more detail.


In Part I of this series I explained how SMTP messages are processed with an Exchange Server, in particular how a Hub Transport Server processes messages from a Mailbox Server.

Figure 1:
The SMTP “Transport Pipeline” in Exchange Server 2010

I already explained how a Hub Transport Server picks up a message from the Mailbox Server to process it. There can be multiple Hub Transport Servers in an Active Directory site.

The Mail Submissions Service on the Exchange 2010 Mailbox Server notifies the Hub Transport Server that a message is in the Outbox. The Store Driver on the Hub Transport Server retrieves the message from the Mailbox Server. RPC is used for communication between the Hub and the Mailbox Server.

After retrieval, the message is stored in the Submission Queue waiting for further processing. The Categorizer picks up the message again and determines where to send it:

  • Back to the Mailbox Server;
  • To another Mailbox Server in the same Active Directory site. Again, RPC is used for communication between the Hub Server and the other Mailbox Server;
  • To another Hub Transport Server in another Active Directory site. Communication between Hub Transport Servers is via SMTP;
  • To the outside world. For sending messages to the outside world (i.e. the Internet) SMTP is used as well.

You can have multiple Hub Transport Servers in one Active Directory site for redundancy and scalability purposes. When you have multiple Hub Transport Servers in your Active Directory site, the Mailbox Servers keeps an internal list of all these Hub Transport Servers. The Mail Submission Service then Round Robins through this list as to notify a Hub Transport Server and to pick up the message from the Outbox. This way the Mailbox Server load balances between all available Hub Transport Servers in the Active Directory Site.

But, before we can send and receive SMTP message we first have to configure the Hub Transport Server with a Send Connector (to send mail) and configure the Receive Connector (to receive mail).

Send Connector

Right out of the box, Exchange 2010 doesn’t have a way to send message to the Outside world. Before you can send message you have to create a Send Connector:

  1. Logon as an administrator on an Exchange 2010 Server and open the Exchange Management Console. Navigate to the Organization Configuration and select Hub Transport. In the results pane, select the Send Connector tab;
  2. The New Send Connector wizard appears. Enter a name for the Send Connector and select its usage (“Internet”) and follow the wizard. Enter * for the address space. This way the Send Connector will be used for all SMTP domains, except for the internal SMTP domains of course.
  3. Next is to select whether you want to use a smart host (an SMTP server with your provider for example) of whether you want to use DNS. In the latter case the Hub Transport Server will be responsible to retrieve all MX records and send the outbound messages accordingly. My personal preference is to use DNS, but you might have valid reasons to use a smart host of course;

Figure 2

  1. In the next Windows you have to select the Source Server. If you have multiple Hub Transport Servers in your Active Directory site you can enter them here. These servers all participate in the Send Connector. SMTP messages will automatically be load balanced across all source servers in the Send Connector;
  2. Finish the wizard and the Send Connector will be created.

The Hub Transport Server is now able to route messages to the Internet.

Receive Connector

By default, a Hub Transport Server will not accept anonymous connections. And connections coming form the Internet are anonymous. Microsoft’s opinion is that you need to use the Edge Transport Server (in your DMZ). The Edge Transport Server does accept anonymous connections from the Internet, and communications between Edge Transport Server and Hub Transport Server is secure. I’ll get back to using an Edge Transport Server in one of the next articles in this series.

But if you want to enable anonymous connections you have to enable this on the Default Receive Connector. Open the Exchange Management Console, Navigate to the Server Configuration and select Hub Transport. In the results pane, select your Hub Transport Server and in the low pane, select the Default Receive Connector and request its properties. Click on the Permission Groups tab to see who is allowed to connect to this Receive Connector. The Anonymous Users is not selected by default as shown in this screenshot:

Figure 3

Check the Anonymous users checkbox and click OK to close the window. The Transport Services needs to be restarted for this setting to take effect. Open an Exchange Management Shell window and enter the Restart-Service MSExchangeTransport command.

We now have a Hub Transport Server that can send and receive SMTP messages to and from the Internet.

Please note that when you use an appliance in your DMZ, for example a Barracuda, IronPort or McAfee solution this is considered as “anonymous” from a Hub Transport Server point of view.

Mail flow to the Internet


When a client creates a new message and clicks the Send button the message is placed in the Outbox. A Hub Transport Server will pickup the message and will place it in the Submission Queue on the Hub Transport Server. In this Submission Queue the message is safely stored on the hard disk of the Hub Transport Server. The Hub Transport Server can crash and reboot, but the message is still safe.

The Categorizer would pick up the message from the Submission Queue and check the To: field in the message to determine the recipients. The routing component of the Categorizer determines the final destination for the message. For Internet delivery, the message is delivered to “SMTP Out” (part of the MSExchange Transport Service) which uses the Send Connector that was created in the previous step. Depending on the address space a routing decision is made.

A queue is created for every message that is sent. This is true for internal messages (back to a mailbox server in the current Active Directory site as well as other Hub Transport Servers in the Exchange organization) and for external messages.

You can view the queues using the Queue Viewer. Open the Exchange Management Console and navigate to the Toolbox section. Select the Queue Viewer in the results pane.

Figure 4


You can see the individual queues, the status, the number of messages in the queue and when there are some issues, the error is shown as well. Using the Queue Viewer you need to connect to every Hub Transport Server so see messages in queues on other servers.

You can also use the Exchange Management Shell to get queue information using the Get-Queue cmdlet. When combined with the Get-TransportServer cmdlet you can see all queues on all Hub Transport Servers:

Figure 5

What’s a reasonable amount of messages in a queue and how long do they stay there? That’s not an easy question to answer. You’ll see quite a number of queues as a result of NDR’s (when spam is sent to non existing users) that cannot be delivered. Typically these queues have only 1 or 2 messages. When there are problems using delivery on the other SMTP hosts, the number of messages will increase. This is the time to start troubleshooting.


In my previous two articles I explained a bit more about the SMTP Routing in the Exchange Server 2007 and 2010 Hub Transport Server Role. These articles were focused on only one Active Directory site. I’ll go into more details when multiple sites are involved.

Active Directory sites

Exchange Server 2003 used the concept of Routing Groups for routing SMTP messages, where Active Directory used the Active Directory sites for exchanging information. In Exchange Server 2007 this was combined and Routing Groups are no longer used and this is true for Exchange Server 2010 as well.

An Active Directory site is associated with one or more IP subnets. Exchange Servers are automatically assigned to a particular site as soon as their IP address is part of one of these subnets. Exchange Server is a so called “site aware” application, which means it has knowledge the site the Exchange Server is a member of, and when it needs services of another server or role (think of a Domain Controller or Global Catalog server) it queries its own site first for these services. Since Exchange Server is site aware it can also use the Active Directory topology for routing messages. It also uses the Active Directory topology for determining other Exchange servers in the same site, possibly with other Server Roles on it. The Active Directory site is the “service discovery boundary” which means the Exchange Server will not look outside its own Active Directory site for other Exchange Servers.

Site membership is determined with a series of DNS queries during startup of the server; the Netlogon service is responsible for this. When you check the DNS entries of your Active Directory you’ll see not only the standard A records but also service records. These service records are used to find other services in the Active Directory site. Site membership is determined by comparing the local IP address with information found in DNS. The Active Directory Topology service also queries Active Directory, by default every 15 minutes, to retrieve a list of Domain Controllers and Global Catalog Server in the Active Directory site. This information is written to the Application Eventlog:

Log Name:      Application
Source:        MSExchange ADAccess
Date:          24-1-2011 10:41:59
Event ID:      2080
Task Category: Topology
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      EXCH01.infra.local
Process MAD.EXE (PID=2484). Exchange Active Directory Provider has discovered the following servers with the following characteristics:
 (Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
DC01. infra.local CDG 1 7 7 1 0 1 1 7 1
DC02. infra.local CDG 1 7 7 1 0 1 1 7 1
AMS-DC01. infra.local   CDG 1 7 7 1 0 1 1 7 1
AMS-DC02. infra.local   CDG 1 7 7 1 0 1 1 7 1

Clearly visible: this Exchange Server has two Domain Controllers (and Global Catalog) in his site, and two other Domain Controller (and Global Catalog) in the Amsterdam Active Directory site.

Every Exchange Server has a property called msExchServerSite. This property is populated with the Distinguished Name of the Active Directory site the Exchange Server is a member of. The Active Directory Topology service is also responsible for populating this property.

Every site that has an Exchange Server 2010 Mailbox must have at least one Hub Transport Server and at least one Client Access Server in the same site. The Mailbox Server uses the Hub Transport Server to send messages to other Mailbox Servers in other sites. So the Mailbox Servers themselves never communicate with each other.

Suppose we have two Active Directory sites and each sites has a Mailbox Server, a Hub Transport Server and a Client Access Server (I’ve not drawn the CAS in this picture).

Figure 1:
Direct delivery from one Active Directory site to another Active Directory site

User1 has a mailbox on MBX01 and he sends a message two User2 who has a mailbox on MBX02. When the message is sent it is picked up by HUB01, the categorizer on HUB01 determines where the recipient is located. User2 is in the same Active Directory, but in another site. Since HUB01 cannot communicate with MBX02 the message is sent to HUB02 in the 2nd site. On HUB02 the messages is stored in the submission queue, picked up by the categorizer and the categorizer determines that the message is a local delivery. The message is now stored in a delivery queue for MBX02 and the message is delivered in the correct mailbox.

Queue at point of failure

A sending Hub Transport Server always tries to connect to the corresponding Hub Transport Server in the other site directly. But when the receiving Hub Transport Server is not available, the sending Hub Transport Server tries to deliver the message as close as possible by determining a so called backoff path. By using the backoff path the Exchange Server tries to deliver the message as close as possible to the recipient’s Hub Transport Server.

Suppose a situation like this: HUB01 wants to send an SMTP message to HUB03 but unfortunately HUB03 is not available. HUB01 determines a backoff path where HUB02 is the next hop in the routing path. The message is delivered to HUB02 where it is queued. The queue will be in a retry state and will try to deliver following the retry settings. As soon as HUB03 is available again the message is delivered. If in the end the message cannot be delivered in a timely manner, the message will expire and an NDR will be sent back to the original sender. This mechanism is called “Queue at Point of Failure”.

Figure 2:
Queue at point of failure. The message is queued on HUB02

Delayed Fan-Out

A typical message can contain not one, but maybe multiple recipient email addresses. Suppose a user in Site-1 wants to send a message to users in Site-3 and Site-4. The message is picked-up by Hub Transport Server HUB01. HUB01 tries to determine the most cost effective way to send all messages and it determines the routing path for each message (i.e. recipient). All routing paths are compared, and HUB01 sends a message to a point where the recipients can be split. This splitting is known as bifurcation in Exchange Server and bifurcation occurs at the point where the message is split.

So, HUB01 sends the message to HUB02 where bifurcation occurs. HUB02 sends a message to HUB03 and HUB04 where the messages will be delivered. This mechanism is called “delayed fan out”.

Figure 3:
Delayed Fan-Out. The message is split on HUB02

Unreachable Queue

There’s one queue I haven’t mentioned so far, which is the unreachable queue. When Exchange isn’t able to determine a valid route for a given recipient the message is placed in the unreachable queue. When Exchange recalculates the routing table and a valid path is determined for this recipient the message will be sent. If no routing path can be determined, the message will expire and an NDR will be sent to the original sender.

Shadow Queue



When you check the queues on a Hub Transport Server using the Queue Viewer of the Get-Queue cmdlet you’ll see message stuck in a shadow queue. You’ll see these messages in this particular queue, even when the messages are successfully delivered.

Shadow queues are a new feature in Exchange Server 2010 which facilitates redundancy on the transport layer of SMTP messages, so it’s a Hub Transport Server feature. This is achieved by deleting sent messages from a queue after the next hop in transit has successfully delivered the SMTP message. If it’s not successful the Hub Transport Server will try to find another route to the final destination.

For example, a Hub Transport Server will send a message to another Exchange 2010 Server, in this example an Edge Transport Server. When the message is delivered to the Edge Transport Server, the Hub Transport Server will store the message in a shadow redundancy queue. The Edge Transport Server will deliver the message to another SMTP Server on the Internet. When the message is delivered, the message will be stored in a shadow redundancy queue on the Edge Transport Server. The Hub Transport Server will periodically poll the Edge Transport Server for successful delivery. If it is successful the message is deleted from the shadow redundancy queue on the Hub Transport Server.

Figure 4

If the Edge Server cannot deliver the message, the Hub Transport Server will know because of this polling. It will try another route and will send the message to the other Edge Transport Server.

In my next article I will explain a bit more about troubleshooting the message flow in an Exchange 2010 environment.

Queue Viewer

As explained in SMTP Routing in Exchange 2010 part 1 that all messages are always stored in Queues. Using the Queue Viewer’s tool it is possible to view the queues and the properties of these queues. Please, note that you can also check the properties of the messages but you CANNOT view the actual messages.

To open the Queue Viewer, open the Exchange Management Console and navigate to the Tools section. There you’ll find the Queue Viewer. When you open the Queue Viewer you can see the SMTP queues on this particular server.

Figure 1:
Queue Viewer on Exchange 2007. It’s the same on Exchange 2010

You can see the status of the queue, the number of messages and the last error the SMTP Service has encountered for this queue. When the status is “ready” and the message count is “0” the message is successfully delivered and the queue will be removed shortly.

The number of messages in a particular queue can grow, but except for NDR’s as a result of spam (sent from a non-existing domain) the queue will shrink automatically within a reasonable amount of time when all is well. If messages cannot be delivered in a timely manner, the messages will be deleted from the Queue, typically within 48 hours and an NDR will be sent to the sender (in your Exchange environment that is). There can be a number of reasons why a legitimate message cannot be delivered. A DNS error, network issues on your side, network issue on the recipient side, server issue on the recipient side, just to name a few…

The queue viewer only shows the queues for one Hub Transport Server. If you want to check another Hub Transport Server you have to select “Connect to Server…” in the Actions Pane and select another Hub Transport Server.

You can also use the Exchange Management Shell to check the queues on the Hub Transport Server (my personal preference) using the Get-Queue cmdlet on the Hub Transport Server:

Figure 2:
You can use the Get-Queue cmdlet to check the queues

When you combine the Get-TransportServer cmdlet with the Get-Queue cmdlet you can see all queues on all Hub Transport Servers. This will give a quick overview, and it is much faster than using the Exchange Management Console.

Figure 3:
Check multiple Hub Transport Servers with the Get-Queue cmdlet

Normally, the SMTP queues will appear and disappear, queues will grow and shrink. If you have a particular queue that’s growing you may want to troubleshoot.

Johan Veldhuis wrote an interesting article regarding Exchange 2010 Queues and the status queues can have. You can find his article here.

The first question of course is “is this a legitimate domain and are there legitimate e-mails?” When you have 150 messages destined for a domain called “” or something like that you can be pretty sure there are 150 NDR’s waiting to be delivered as a result of SPAM.

The queue will be automatically cleaned up typically after 48 hours or so, but if you want to empty the queue immediately, open the Exchange Management Shell and enter the following CMDLets:

Get-Message -Queue “<<server>>435” | Remove-Message -Confirm:$false

Assuming of course that the messages are in queue 435, but this will vary per situation. If the queue is for a valid domain check the last error of the queue. When it’s a DNS issue check the MX records using the NSLOOKUP utility. Open the NSLOOKUP utility and set the query type to MX and enter the domain name. It will show the MX records and the accompanying A records of the mail servers:

Figure 4:
Use the NSLOOKUP tool to gather information regarding external mail servers.

The next step is to check if there’s network connectivity to these mail servers by using the PING command. When successful use the Telnet Client utility to open a connection on port 25. The Telnet Client utility is not installed by default (unfortunately) but use the Windows 2008 (R2) Server Administrator to install the Telnet Client utility. It can be found under the Features option.

Using the Telnet Client utility, open a connection to the recipients SMTP host on port 25:

Figure 5:
Use TELNET to open a connection and check if you can send a test message

When checking the mailbox we can see the message has actually arrived:

Figure 6:
The test message from TELNET has arrived!

So, using the Get-Queue cmdlet combined with the NSLOOKUP, PING and TELNET client you have a very powerful set of tools for troubleshooting the message flow. If you’re not familiar with the Telnet possibilities in combination with the SMTP Service please check out the following Microsoft article here.

Transport Logging

Another way of troubleshooting the SMTP transport is by means of protocol logging. The SMTP service has the ability to log all actions it performs. Because it logs everything this functionality is disabled. Enabling it can be useful but should only be used for troubleshooting purposes. If leaving this enabled in a production environment the local disks will quickly fill-up with logging information, and a completely filled boot and system disk generally means a dismounted server.

To enable protocol logging on an SMTP connector, open its properties in the Exchange Management Console and set the “Protocol Logging Level” to verbose on the General tab:

Figure 7:
Enable logging on the connector

The SMTP Transport logs are now stored on the following locations:

C:Program FilesMicrosoftExchange ServerV14TransportRolesLogsProtocolLogSmtpSend or C:Program FilesMicrosoftExchange ServerV14TransportRolesLogsProtocolLogSmtpReceive

There are tons of information in these log files and they can be very useful for troubleshooting the SMTP communication between servers.

There’s one nifty issue though! Check out the following screen shot from the Exchange Management Console where an Edge Server is used in combination with a Hub Transport Server:

Figure 8:
Only Edge related connectors are visible, not the connector between Hub and Edge Servers

If SMTP transport logging is enabled on these connectors, logging will occur on the Edge Transport Servers. There’s no way here to enable logging from the Hub Transport Server. The same is true for SMTP traffic between Hub Transport Servers in different Active Directory sites.

For these purposes a hidden connector is used, and protocol logging should be enabled on this hidden connector. This can only be performed using the Exchange Management Shell by entering the following cmdlet:

Set-TransportServer EXCH01 –IntraOrgConnectorProtocolLoggingLevel Verbose

Now logging will be enabled on connectors between the Hub Transport Server and the Edge Transport Server and between Hub Transport Servers in different Active Directory sites.

Routing Table Viewer

In my previous article regarding SMTP Routing I talked about the Routing Table on a Hub Transport and Edge Transport Server. This Routing Table is an in-memory table containing the Exchange organization’s routing infrastructure. This Routing Table is automatically calculated based on information found in Active Directory or sent from the Hub Server to the Edge Server in case of an Edge Transport Server.

The SMTP Service takes a snapshot of the Routing Table periodically and saves it to disk. This snapshot is taken:

  • After a fixed amount of time;
  • When the Transport services is (re)started;
  • When the routing configuration changes.

To view these snapshots, open the Exchange Management Console, navigate to the Tools section and open the “Routing Log Viewer”. There’s information regarding the Active Directory Sites, Routing Groups, Exchange servers, Send Connectors and Address spaces.

Figure 9:
A snapshot of the Routing Table on a Hub Transport Server

Tracking Log Explorer

All messages that are sent or received by an Exchange organization are logged in so called “Message Tracking” log files. These log files are large text files (stored in C:Program FilesMicrosoftExchange ServerV14TransportRolesLogsMessageTracking) and can be searched by a tool called “Message Tracking Explorer” which can be found in the Tools section of the Exchange Management Console.

There’s also a tool called “message tracking” under the Tools section, but this one will redirect to the Exchange Control Panel. This part is about the Tracking Log Explorer, a separate entry under the Tools section in the Exchange Management Console.

The Message Tracking Explorer can search on Sender, Recipient, Subject, Message ID etc. And EventID can be selected, like Send, Received, Submitted, etc.

The Message Tracking Explorer can be used for troubleshooting when users complain about messages that are not received or got lost or something. Of course these messages can only be searched within the Exchange organization. When messages are sent outside the Exchange organization they’re ‘out of sight’ and further message tracking is no longer possible.

Figure 10:
Message Tracking in Exchange 2010. Note the corresponding Powershell command.

One side step regarding the message tracking log files. From a compliancy perspective it can be necessary to back up the message tracking log files in your (daily) backup cycle. This way the message tracking log files don’t get lost in case of a server failure. As mentioned earlier, the message tracking logs can be found in the directory C:Program FilesMicrosoftExchange ServerV14TransportRolesLogsMessageTracking. Be aware that these log files can grow significantly!



In a series of articles I explained the functionality of the SMTP Transport Service in Exchange Server 2007 and Exchange Server 2010, also sometimes referred to as the Transport Pipeline. We’ve seen internal routing, external routing, send and receive connectors and in this final article I explained a bit more regarding troubleshooting and logging on the transport service. By default most functionality is enabled, but for troubleshooting purposes it is needed to tweak a bit more.

How To Install MS Exchange 2013 Server

Preparing Active Directory for Exchange Server 2013


When you are installing Exchange Server 2013 for the first time the Active Directory needs to be prepared.

There are a series of requirements for Active Directory preparation to be successful:

  • Schema master running Windows Server 2003 with SP2, or a later version of Windows Server
  • At least one Global catalog server per site that Exchange will be installed in that is running Windows Server 2003 SP2 or later
  • At least one Domain controller per site that Exchange will be installed in that is running Windows Server 2008 or later
  • Forest functional mode of Windows Server 2003 or higher
  • An account with Schema Admins, Domain Admins, and Enterprise Admins permissions to run Exchange setup

Although Active Directory preparation can occur as part of the installation of the first Exchange Server 2013 server, you can also run the Active Directory preparation as a separate task beforehand on a 64-bit server running Windows Server 2008 or higher.

Because the Active Directory preparation requires the RSAT-ADDS tools I am running it on the domain controller in my test lab.

Alternatively, you can install the tools on a member server to run Exchange 2013 Active Directory preparation.

For Windows Server 2008 R2 (SP1 or later), in PowerShell run:

Import-Module ServerManager Add-WindowsFeature RSAT-ADDS


For Windows Server 2012, in PowerShell run:

Install-WindowsFeature RSAT-ADDS

If you are installing Exchange Server in the AD forest for the first time run the following Exchange 2013 setup command to prepare Active Directory:

setup /PrepareAD /OrganizationName: "your organization name" /IAcceptExchangeServerLicenseTerms

Note: if your organization name contains spaces then it must be enclosed in quotes as shown above.

If an Exchange organization already exists you can omit the /OrganizationName parameter.

setup /PrepareAD /IAcceptExchangeServerLicenseTerms


Installing the Exchange Server 2013 Pre-Requisites

Exchange Server 2013 can be installed on either Windows Server 2008 R2 (SP1 or later) or Windows Server 2012. Depending on the server roles you are installing the pre-requisites vary. 

Installing Exchange Server 2013 Using the Setup Wizard

After installing the pre-requisites a restart of the server may be required. If you proceed without restarting then setup may be unable to proceed when it detects the pending restart.

From the location where you have stored your Exchange 2013 files run Setup.exe.

The first dialog gives you the opportunity to check for updates to the setup files before you proceed.

Check for updates to Exchange 2013 setup files

After the setup files have updated click Next to continue.

Click Next to continue past the Introduction message.

Exchange 2013 setup introduction

Accept the license agreement and click Next to continue.

Exchange 2013 license agreement

Choose whether or not to enable Error Reporting and click Next to continue.

Configure Exchange 2013 error reporting

After a check that all the pre-requisites are installed the setup wizard will move on to the next step automatically (if the check was successful).

Now we can choose the server roles to install. If this is the first server you’re installing Microsoft recommends you install the Mailbox server role first (this can be either a Mailbox-only server or a combined Mailbox/Client Access server).

Choose the Exchange 2013 server roles to install

Verify that you have enough disk space for the installation, or choose a path that does have enough disk space, and click Nextto continue.

Choose the location to install Exchange 2013

If there is no existing Exchange organization in Active Directory, and you haven’t already prepared Active Directory for Exchange, you will be prompted to enter an Exchange organization name.

When installing the Mailbox server role you are given the option to disable malware protection. If you disable it now you can enable it again later.

Configure anti-malware protection for the Mailbox server

Some readiness checks are performed. If this is the not the first server you’re installing and there is no Send Connector defined for outbound email then you may see a warning, but you can still proceed with the server installation.

Setup can’t detect a Send connector with an address space of ‘*’. Mail flow to the Internet may not work properly.

Exchange 2013 setup pre-requisite warning

When you are ready to proceed you can click Install to begin.

Begin the installation of Exchange 2013

The install is a fairly lengthy process, so you may want to go and do something else while you wait. When setup has finished click Finish.

Exchange 2013 setup is finished

How To Create Send Connector on Hub Transport Server in Exchange 2007

To create the SMTP Connector in Exchange 2007:

  1. Open Exchange Management Console (ESM)
  2. Navigate to Organization Configuration | Hub Transport in the left-hand pane
  3. Click on the Send Connectors tab in the center pane, then in the right-hand Actions pane, select New Send Connector:


  4. Add a Name for the new connector (e.g. Mimecast Connectors). Also, set the intended use for the Send connector to Custom, then click Next:


  5. Select the + Add… button to create a new SMTP Address Space with the details given below:

    Ensure that the details for the Address Space are entered as follows:

    Address: = *
    Cost: = 1


  6. Click OK then select Next.
  7. Under Network settings, select the option Route mail through the following smart hosts, then click the +Add button:


  8. Select the option Fully qualified domain name (FQDN), enter the details for the first Mimecast service address as supplied by the Mimecast Connect Team, then click OK:
    North America

    South Africa



  9. Repeat the previous step to add the FQDN for the second Mimecast service address supplied, then click OK:


  10. Leave the smart host authentication setting as None by default, and click Next:
  11. By default, the server that you are currently working is listed in the Source Server page.  Select the +Add… button to choose a different Source Server and click Next:


  12. Under New Connector, review the Configuration Summary to ensure that the details are correct and then click New. This will create the Send connector and test the new connector:


    You can copy the contents of this page (and the next one) to your preferred text editor to save the Connector details.
  13. Once the connector has been tested, click Finish to close the dialog:


  14. Disable or remove any other Outbound Send Connectors that were previously used. Failure to do this means your outbound email still uses these older send connectors and is not routed through Mimecast. Any send connectors used for other purposes (e.g archiving) may still be required to be enabled.