Exchange 2013: New Features and Changes, Part 2

Mail Access
Outlook Web App (OWA) interface
Outlook Web App features numerous changes, but the most obvious is definitely the visual appearance, which now sports a sleeker and cleaner interface. Running OWA is almost the same end user experience as running Microsoft Outlook. Some organizations can consider leveraging the OWA interface as an alternative to the full messaging client.

OWA cache functionality
This key feature allows a user to to access OWA e-mail while the client is offline, since a local cache can be created in certain browsers (IE 10 and Chrome, for example). The cached content, stored in a web database format, includes e-mail and contacts, as well as calendar content. Recent content can be read, edited, saved as a draft, etc., basically allowing users to perform most common tasks while being offline and disconnected. This is a key feature of Exchange 2013 and will help users leverage OWA. It has the potential to become a real alternative to the full Outlook client.

The Remote Procedure Call (RPC) protocol
In legacy versions of the product, RPC was leveraged in quite a few scenarios. With RPC, a large numbers of ports had to be opened on firewalls, which allowed the Outlook client (internally connected) to reach the Client Access Servers. Also, a similar situation happened when communication between the mailbox and CAS or hub roles occurred.

In Exchange 2013, RPC is still used, but it is encapsulated within HTTPS in all instances. Communication between the previously mentioned components now all occurs through SSL, delivering more flexibility when dealing with mailbox proxying and client access.

There are other advantages with this kind of configuration, including less overhead because of the RPC service running on the CAS, the use of mailbox Globally Unique Identifiers (GUIDs), better site resiliency, and enhanced mailbox proxying.

Mailbox proxying
The optimal client connectivity scenario involves a user accessing a CAS found on the same site where the client mailbox resides. However, that does not always happens, as the client can access the wrong physical network, forcing redirection or proxying to occur.

In earlier versions of Exchange, we could use HTTPS proxying to help that remote client gain access to the mailbox through CAS to CAS communication.

For example, if a user connects to Site 1 and the target mailbox is on Site 2, Site 1 CAS proxies the connection to Site 2 CAS, where the mailbox server hosting the e-mail of this user is found. The Site 1 CAS is considered a relay, helping maintain the connection to the mailbox.

Depending on the connectivity method and topology design used, redirection or proxying had to be involved often, as mailbox and CAS servers that were in different sites could not communicate by design. The result was increased traffic between WAN links, and a greater utilization of the CAS servers, reducing the overall performance of the messaging infrastructure.

Exchange 2013 still uses proxying, but it is no longer necessary to involve CAS-to-CAS communication between sites, as a CAS and a mailbox in separate sites can now communicate directly. Based on the scenario above, this means we eliminate the additional connectivity of the relay CAS server in Site 1. This simpler configuration minimizes the need for the resource-intensive RPC protocol on WAN links.

Super proxy functionality
The CAS component in Exchange 2013 differs highly from the one we used with previous versions. In fact, the actual workload is not being performed on the CAS anymore; the data is rendered by the mailbox role and only displayed by the CAS. That not only means more load for the mailbox servers, but also a greater flexibility when it comes to designing the CAS infrastructure. Since these two servers share less information in common now, the CAS no longer needs to retain session-state and connectivity information. The CAS acts as a true proxy solution and will operate under different versions than the mailbox server runs on. It is presented now as a reverse-proxy solution.

However, it is still necessary to have both the mailbox and CAS on the same site, with appropriate other infrastructure servers (Active Directory [AD], DNS, global catalogs, etc.), just as in previous versions.

Managed Availability
This new feature provides a way to isolate and fix issues that can potentially affect the user experience. It can detect various problems and provide a way to fix them on the fly.

In short, it is composed of three parts:

A probe: This component acts as a monitor, taking samples and measurements of the end user mailbox access.
A monitor: The monitor analyzes the information provided by the probe to help find connectivity issues.
A responder: There are multiple responders designed to take action when the previous components discover a problem.

Unified Messaging (UM)
With these numerous changes at the infrastructure level, you might notice UM is not available as an option through the installation wizard. In fact, Unified Messaging has been split into two pieces, similar to the SMTP services, but has kept the same functionalities and is present on CAS as well as mailbox roles.

The UM call router service forwards calls to Mailbox Servers, performing the transport and proxying functions.

The UM service that runs on the mailbox server is responsible for the majority of the processing. This is where information such as auto attendants, gateways, dial plans, and other VoIP functionality is defined and used in UM scenarios.