Introducing Microsoft Exchange Server 2013 : Preparing for Exchange 2013

The situation is relatively simple for client access servers, all of which run a front-end transport service that is designed to handle all inbound and outbound SMTP traffic going to or coming from external systems. The transport service running on these servers primarily handles getting mail in and out of Exchange and performs very little content inspection (domains, connections, senders, and recipients). The transport service on a client access server communicates with the transport service on mailbox servers to send and receive messages, but in line with the intention that the client access server should be as stateless as possible, it never queues any messages locally.

If you’re upgrading from Exchange 2010 or Exchange 2007, you would consider the Transport service that runs on mailbox servers to be very similar to the processing that hub transport servers perform in those versions, with one extremely important difference. The Transport service handles SMTP mail flow and performs the kind of message categorization and content inspection that you expect from previous versions. However, it never communicates directly with mailbox databases, which is a task assigned to the separate Mailbox Transport service. You can think of the Transport service as the intermediary between the front-end Transport service that runs on client access servers and the Mailbox Transport service that deals with mailbox databases. It is also responsible for managing message queues and stores any queued messages in its transport database.

The Mailbox Transport service is designed to route messages to databases. It actually consists of two components. The Mailbox Transport Delivery service processes inbound SMTP messages from the Transport service and connects and delivers the messages to the currently active copies of the mailbox databases that hold the destination mailboxes by using remote procedure call (RPC). On the outgoing side, outbound messages that originate in Exchange mailboxes are processed by the Mailbox Transport Submission service, which connects to the database and retrieves the messages before submitting them through SMTP to the Transport service to be categorized and routed.

This sounds very straightforward, but the details are explored in depth in Exchange Server 2013 Inside Out: Connectivity, Clients, and UM. For now, you know enough to continue with a discussion about the mailbox server.

Successful preparation always involves dedicated effort to test more than once to ensure that new software works well in the environment run by a specific company. You must protect yourself from unexpected behavior by designing and executing a comprehensive test plan. The plan should address these points:

Apart from the purely functional testing, you should also test how well Exchange 2013 will function in your operational environment. There are many changes in the software that will cause you to change operational processes and procedures in different areas. For example:

Not everyone wants to exploit the range of APIs and programmable interfaces available to access Exchange data, but you might be surprised when you start to analyze the range of features that people use to work with Exchange in your company and see that different ways of accessing information are important to different groups. Test to ensure that you can continue to deliver the same degree of service to end users after Exchange 2013 is deployed, no matter how they access data. End users include administrators, so interfaces between Exchange and other products (both Microsoft and third-party) are important areas to explore and understand. Some items to keep in mind include the following:

The prospect of going through a migration from one version of an email server to another is never appealing. Depending on your requirements, it might be better to plan for a very different approach such as outsourcing Exchange to a third party, using a traditional on-premises deployment, taking a cloud-based approach through Office 365, or using another hosted offering based on Exchange 2013.

If you run Exchange 2007 today, it’s likely that you have deployed SP3, the last major update, released in mid-2010. Apart from essential maintenance delivered through regular updates containing cumulative bug fixes and some improvements to features, Exchange 2007 is approaching its natural end of life and doesn’t receive much development attention. To prepare for the introduction of Exchange 2013, you need to deploy Exchange 2007 SP3 RU10.

Exchange 2010 is a newer product, only recently replaced by Exchange 2013. Nevertheless, at the time of writing, it also has had three service packs. Exchange 2010 SP3 is the minimum version you need to install to coexist with Exchange 2013. Apart from bug fixes and other code updates, these versions of Exchange understand the new Active Directory schema introduced to define new objects such as site mailboxes used in Exchange 2013. Schema upgrades have to be replicated around the complete Active Directory forest, so this task has to be factored into your deployment plans. Another advantage of deploying Exchange 2010 SP3 is that this release supports Windows Server 2012. This might be important to you if you want to deploy all your servers running Exchange on the same operating system. No version of Exchange 2007 supports Windows 2012.

If you have to update earlier versions of Exchange Server to coexist with Exchange 2013, you might have to update third-party products, too, with a release that vendors have validated to work well with the earlier software. Third-party products might also have to be updated for Exchange 2013 (and verified against the latest cumulative update), so it’s a good idea to create a full list of software that runs on your servers that run Exchange and check each product to establish which version is required to support Exchange 2013.

The possibility exists that you might want to deploy some earlier versions of Exchange servers inside a brand-new Exchange 2013 organization. On the surface, this shouldn’t be a problem because Exchange 2013 can coexist with Exchange 2007 and Exchange 2010 in the same organization. However, the order in which you deploy servers is important. If you begin an organization with a server running Exchange 2013, you can install only Exchange 2013 servers in that organization because beginning with Exchange 2013 will render the organization incapable of supporting earlier versions. Therefore, if you think you will need to use Exchange 2007 or Exchange 2010 now or in the future, perhaps to support an application that hasn’t yet been upgraded to support Exchange 2013, start by installing a server running the earliest required version (Exchange 2007 or Exchange 2010; you can’t run Exchange 2003 alongside Exchange 2013), and then add Exchange 2010 servers if required. Then deploy Exchange 2013. The earlier versions of Exchange servers don’t have to be active. They simply have to exist in the organization as markers to create the conditions to permit support of a multi-version organization.

When you reach the point at which the earlier versions of Exchange servers will never be required again, you can remove the servers.