Exchange Server 2013 : Types of Exchange Client (part 2) - Web Browsers, Exchange ActiveSync, Collaboration Data Objects

Web Browsers

In Exchange terms, web browsers are basically users of the Outlook Web App (OWA). It is often useful to discuss browser-based mail clients because of the huge number of web browsers in use in your organization and Exchange Server 2013's varying support of them.

Browser-based mail clients are becoming more and more popular, largely due to the flexibility and rich feature set that OWA provides combined with operating system independence and the pervasive nature of web browsers. Fundamentally, each release of OWA has attempted to imitate the look and feel of the most current Outlook client. For Exchange Server 2013, this means that OWA looks very similar to Outlook 2013.

By far the most beneficial aspect to browser-based mail clients is that they require no configuration whatsoever. The end user just needs to know the correct URL for the web-based client and to enter their username and password to be provided with a feature-rich experience. The actual features offered vary depending on the browser and operating system, but for the most part, even the poorest OWA experience is far better than using a POP3 or IMAP4 client. This is because, although you may be able to connect a feature-rich client such as Outlook 2013 to Exchange Server 2013 via POP3, many of the rich client features will be disabled, such as availability information and the global address list.

OWA does have limitations, however. Among the most notable restrictions are that performance can suffer over a poor network connection and a reduced set of notifications is available because of browser constraints. Nevertheless, roaming or occasional email users will find OWA perfectly acceptable and sometimes prefer it to an installed desktop application. OWA in Exchange Server 2013 also supports offline mode with some browsers, which means that OWA can cater to even more user scenarios. Even though OWA provides a feature-rich experience, power email users often prefer to use a rich client, such as Outlook connected via MAPI or Outlook Anywhere, because of its better performance and ability to work with local data files (.pst).

Exchange ActiveSync

Exchange ActiveSync (EAS) is an email protocol, just like MAPI, except it is primarily used in mobile clients, such as smartphones or tablets. Consequently, it is optimized for low-bandwidth and high-latency scenarios, such as over packet-switching radio data networks. The protocol also provides specific functions for mobile devices, such as being able to wipe the device remotely and to control aspects of the mobile device via security policies.

A complete list of policies that can be configured via the ActiveSync protocol can be found here:

http://technet.microsoft.com/en-us/library/bb123783.aspx

EAS is one of the most misunderstood protocols for Exchange. Many believe that Microsoft sells EAS and provides third-party manufacturers a finished mobile email product. This is partially true in that Microsoft does sell a license to use the EAS protocol. Microsoft does not, however, provide a finished email client as part of this license. Each EAS licensee is afforded access to the EAS protocol specification and a license to sell devices that use this protocol.

At the time of writing, there are 52 licensees of the EAS protocol, including Apple, Nokia, Google, Sony, Samsung, and HTC to name just a few. The EAS licensee may develop their mobile client in any way they wish. Accordingly, though virtually every mobile device on the market supports EAS, each device is likely to offer a different implementation of the protocol and may support only a subset of its features.

This results in a double-edged sword for EAS. It is an outstanding protocol for connecting mobile devices to Exchange Server. Most mobile devices provide rudimentary support for autodiscover, which makes the initial configuration very simple and enables the devices to provide a rich user experience via EAS. However, not all devices support every EAS feature, and most devices have their own idiosyncrasies, which range from not fully supporting autodiscover to causing backend Exchange Server issues.

Microsoft attempted to resolve this problem by launching the Exchange ActiveSync Logo Program. This program is defined as follows:

Initially, this seemed to be a great idea. After the initial enthusiasm passed, however, few vendors actually submitted devices. The website for this program today lists Apple iOS 4.3 and Microsoft Windows Phone 7.5, neither of which are current platforms; Google has not submitted anything.

Apple iOS 6.2 was released in February 2013, and this caused Exchange servers to generate huge quantities of additional transaction logs. Apple fixed this with 6.2.1 shortly afterward. Back in June 2010, Apple released iOS 4, which caused severe performance issues when it connected to an Exchange server. Apple eventually issued iOS 4.0.1, which fixed the problem.

We mention these specific events because it is important to remember that the type of client device may not only impact the end-user experience but may also affect the Exchange service itself. Apple is not the only vendor to produce a buggy EAS client (and they won't be the last). However, because of the sheer number of their devices on the market, they are one of the most important.

Collaboration Data Objects

During Exchange design projects, it is easy to slip into a frame of mind where you think only about end-user mailboxes. You imagine your Exchange servers being deployed and providing a great new service to end users. However, it is extremely rare to find an Exchange deployment that does not also have some form of application integration.

Application integration occurs when another program or service needs to use the Exchange service. This integration could be as simple as sending or receiving email to something more exotic such as managing field agents' calendars based on a booking application service. Regardless of the function required, the most common mechanism used to access Exchange Server programmatically is via the Collaboration Data Objects (CDO) model. Despite this model being deprecated in Exchange 2007 in favor of Exchange Web Services, it is still very common today.

At its core, CDO exposes the MAPI protocol to programming languages via the Component Object Model (COM). Back when it was introduced (in Exchange 4.0 and called OLE Messaging), this was useful because many applications were written in Visual Basic, and could not use the MAPI C++ libraries directly.

A number of high-profile applications use CDO, such as BlackBerry Enterprise Server (BES), Good Messaging for Enterprise, and Enterprise Vault. We mention this since Exchange Server 2013 will be the last version of Exchange to support CDO; the next version of Exchange Server will not provide a CDO library. This means that all future Exchange application integration will move over to Exchange Web Services or POP3/IMAP4.

Since Exchange 2013 still supports CDO, two points are worth mentioning: First, CDO for Exchange Server 2013 is not available at the time of this writing. Second, vendors will be required to update their applications to use the Exchange 2013 version of CDO because of the change in MAPI connectivity; that is, Exchange 2013 enforces HTTPS Outlook Anywhere client connections only. Accordingly, it is highly recommended that you speak to your software vendors to obtain a product support roadmap for Exchange Server 2013. Be warned that it may take them longer than normal to provide an update given these changes to CDO and MAPI.

http://blogs.msdn.com/b/stephen_griffin