Chapter 12

Exchange Clients

One the reasons behind the success of Exchange Server is that it supports many client types. It is possible to connect to an Exchange mailbox from pretty much any operating system. The experience provided by clients varies so dramatically that end users may not even realize that they are using an Exchange Server.

A great example of this took place on a university campus in the United Kingdom. The university had migrated their messaging service to Microsoft Live@edu. The Live@edu service was basically Exchange Server 2010 hosted in the cloud. The university students were provided instructions on how to connect to the new service when using Outlook for either Windows or Mac and also for Linux clients using IMAP. After the migration, a computer science class was overheard talking about how good the new mail service was now that it was running on Unix. They had no idea that they were connecting their open source Linux workstations into a Microsoft Exchange Server, but they were impressed with the service all the same.

There are downsides to this flexibility, however. Not all clients have the same resource usage requirements, and so it can be difficult to project your server sizing numbers with precision if you do not have detailed client inventory data. Additionally, many clients that can connect to Exchange are produced by third-party suppliers or are open source. This means that there is a greater chance of bugs or unpredictable behavior among the clients that impact the Exchange service that you have deployed.

This chapter will address ways in which clients differ and how they may impact your design and deployment approach for Exchange Server 2013. We will also discuss some enhanced features in Exchange 2013 that help protect your Exchange 2013 servers from rogue clients.

Types of Exchange Client

There are a huge number of different email clients that can connect to Exchange Server. This is due to Exchange providing support for standards-based email protocols, such as Post Office Protocol (POP3) and Internet Message Access Protocol (IMAP), in addition to Microsoft's proprietary Messaging Application Programming Interface (MAPI). There are also several open source implementations of MAPI, such as OpenMapi, MAPI4Linux, and libmapi, which allow open source email clients to connect to Exchange Servers directly via MAPI.

Because of the number of client types, most design teams group them together based on their protocols.

Messaging Application Programming Interface (MAPI/RPC)

MAPI has been around in one form or another since 1991. Initially, it was used as the protocol for the MS PC Mail product. It was later developed into extended MAPI and used within Exchange Server.

Outlook Does Not Only Use MAPI

From a client perspective, Outlook is the most common MAPI client used with Exchange Server. Nevertheless, just because Outlook is in use does not guarantee that it is connecting via MAPI, especially in open environments such as universities. Remember that Outlook supports other protocols that can be used to connect to Exchange Server, including IMAP and POP3, and with Outlook 2013, even Exchange Active Sync is supported, which allows it to connect to Outlook.com. Although Outlook does not necessarily imply a MAPI connection, a MAPI connection usually implies Outlook since it is the only MAPI client that is supported by Microsoft for connecting to Exchange Server.

It is worth defining MAPI at this point and how it has changed in Exchange Server 2013. At its core, the Messaging Application Programming Interface is a Remote Procedure Call (RPC) protocol that provides a very rich interface to your Exchange mailbox. One of the main differences between MAPI and Internet standards-based protocols, such as POP3 and IMAP, is that MAPI requires high-speed network connectivity and multiple TCP ports in order to connect. This is in contrast to POP3 and IMAP, which were designed to operate over unreliable Internet connections and through firewalls.

MAPI is still used in Exchange 2013. However, it has been encapsulated within an HTTPS tunnel. HTTPS is a secure version of the World Wide Web protocol (HTTP), which is encrypted with a certificate. Encapsulating MAPI within HTTPS was done to simplify the authentication and connectivity model within Exchange 2013. It is important to remember that MAPI is still alive and well, and that it is merely hidden within an HTTPS connection.

This type of MAPI connection is known as Outlook Anywhere in Exchange terminology. Outlook Anywhere was available in previous versions of Exchange, where it was mainly used to allow Outlook clients to connect over the Internet to Exchange Servers via MAPI encapsulated within an HTTPS tunnel.

Exchange Web Services

Exchange Web Services (EWS) has been the recommended application programming interface (API) for Exchange Server since Exchange Server 2007. EWS is a web-based protocol that communicates over HTTPS with Exchange Server. The most common user-based EWS clients are on Apple OS X. Apple OS X 10.6+ includes a native mail client, called Mail, which supports EWS connections, and Microsoft Office 2011 for Mac includes Outlook 2011, which also uses EWS to connect to Exchange. Prior to Outlook 2011 for Mac, Microsoft provided Entourage 2008 Web Services Edition, which also supported EWS.

From a client perspective, EWS provides a very similar set of features to MAPI. It is not as efficient as MAPI over the network, however, and so it can often appear to take longer to send or receive email on an EWS client than for Outlook connected via MAPI.

EWS is not restricted to end-user client use, though, and it is also frequently used by applications that require mailbox access. The move to EWS for application integration with Exchange has increased dramatically since Microsoft made Office 365, which runs Exchange in the cloud, available. This is because the recommended API into this service for applications is EWS. Some applications also use POP3 and IMAP4 for application integration. This has prompted developers to rewrite many applications that had previously used the Common Data Objects (CDO) API to use EWS instead.

POP/IMAP

The Post Office Protocol was first defined in 1984, and it became ubiquitous as the standard email protocol in the early days of the Internet. Virtually every email client supported POP, largely since it was extremely simple, lightweight, and very reliable. The current implementation of POP is known as POP3, which was defined via RFC 1081 in 1988. POP3 is still in use today, and Exchange 2013 supports it.

The Internet Message Access Protocol was first defined in 1986 as the Interim Mail Access Protocol, before eventually being renamed to Internet Message Access Protocol Version 4 in 1990. IMAP4 was an attempt to improve on POP3 and provide a richer client experience, including the following features:

Ability to leave messages on the server
Multicomputer access
Power to synchronize multiple folders (including sent items)
Ability to work offline
Improved error handling

Since POP3 and IMAP4 are totally unrelated protocols, why do we often group the clients together? The answer here relates more to client commonality than to the individual protocol used. For instance, most clients that support POP3 also support IMAP4. These clients are typically not Active Directory domain-joined and also typically connect over the Internet.

Another use of both POP3 and IMAP4 is for application integration with Exchange Server. POP3 and IMAP4 are extremely simple protocols to use, and so many developers use them when they need to read or write data to an Exchange mailbox.

By far the biggest problem with both POP3 and IMAP4 is the tendency for clients and application developers to send credentials in clear text over an unencrypted connection. Both of these protocols can be secured via the use of encryption certificates. The credentials will still be sent in clear text over an encrypted tunnel, but they are protected by the tunnel encryption. Be mindful, though, that not all clients support the secure version of each protocol, and many applications that were developed to use POP3 or IMAP4 are old and may require an upgrade to function securely. In Office 365, only encrypted POP3 and IMAP4 are supported.

Enabling POP3 and IMAP4 in Exchange Server 2013

By default, both POP3 and IMAP4 are disabled in Exchange Server 2013. To enable POP3 and IMAP4, you must start the appropriate services on your Exchange 2013 servers. One change from previous versions of Exchange Server is that there are now two services for each protocol.

To enable POP3, run the following PowerShell cmdlets as an administrator:

Set-service msExchangePOP3 -startuptype automatic
Set-service msExchangePOP3BE -startuptype automatic
Start-service msExchangePOP3
Start-service msExchangePOP3BE

To enable IMAP4, run the following PowerShell cmdlets as an administrator:

Set-service msExchangeIMAP4 -startuptype automatic
Set-service msExchangeIMAP4BE -startuptype automatic
Start-service msExchangeIMAP4
Start-service msExchangeIMAP4BE

Note that the Backend service (POP3BE/IMAP4BE) will exist on Mailbox roles and the normal protocol service will exist on Client Access Servers. If you have installed both Mailbox and Client Access on the same server, both services will be present.

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. We will address browser support later in this chapter.

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).

Spell-Check in OWA

By far the biggest cause of irritation in the Exchange Server 2013 OWA is the removal of spell-check from the application and its reliance on the web browser to provide this feature. Luckily, most operating systems support a web browser that provides spell-check natively. One word of caution here is that Internet Explorer 9 on Windows 7 does not provide spell-check, so Windows 7 users will need to upgrade to Internet Explorer 10, Google Chrome, or Firefox to regain the spell-check feature in OWA 2013.

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:

The Microsoft Exchange ActiveSync Program for mobile email devices that connect to Exchange Server and Exchange Online ensures that customers and IT pros have seamless experiences with setup, support, and use of qualified devices. Only products that meet Exchange ActiveSync Logo Program requirements will be listed.

http://technet.microsoft.com/en-us/exchange/gg187968.aspx

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.

MAPI Internals Blog

Stephen Griffin is a Microsoft employee who maintains a blog dedicated to MAPI and CDO development. If you need to delve more deeply into this area, we strongly recommend spending some time reading through his excellent material.

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

Why Does Client Choice Matter?

For all but browser clients, the client type that is deployed defines the end-user experience. It is not unusual for Exchange Server migrations to occur and for end users not even to notice that they have been migrated since their experience remains virtually the same.

While not a hard-and-fast rule, the Exchange Server software typically provides benefits in terms of service availability and reductions in operation and deployment costs. Client software generally provides improvements in the end-user experience. The obvious exception to this is Outlook Web App browser clients, because they, along with mailbox quota limits, change with each version of Exchange deployed. It is very common for Exchange upgrades to bring about larger mailbox sizes. It is also just as common, however, for end users not to notice this additional space.

To achieve good Exchange design, it is vital to bring client choice into the design process and consider the client as part of the overall service being developed. After all, the client is a fundamental piece of the solution.

User Experience

User experience is the term used to describe how a user perceives the service or application that they are using. Thus it is a somewhat subjective value where individuals may rate their experience differently. From an Exchange client perspective, this means that everyone may not have the same user experience with the same client. For example, one user may be satisfied with a super-lightweight client such as Eudora because of its simplicity and speed, whereas another user requires features found only in Outlook 2013 for Windows.

Client Responsiveness Is Not Always an Issue with Exchange

Client responsiveness is another feature that is often missed during Exchange service design. We witnessed a great example of this type of omission from a customer who had deployed Exchange Server 2010 successfully. They had increased mailbox quota sizes from 100 MB to 5 GB by moving to Exchange Native Data Protection and low-cost, locally attached storage. The project was thought to be a great success by all metrics. Nevertheless, we were asked to help this customer less than 12 months after their migration because “Exchange was slow” and, despite their best efforts, they were unable to determine the reason why. After a short analysis, we concluded that Exchange was actually performing very well, even though the end users were complaining of poor performance. Further analysis indicated that most of the users who were complaining were using laptops with 5.4K RPM hard disk drives and an old version of an antivirus software program. The combination of additional disk I/O caused by the larger Outlook cache file (.ost), slow hard disk drives, and an overly aggressive antivirus software configuration was causing delays of 3–5 minutes for Outlook to open, and client responsiveness was terrible in general. The customer replaced the older laptops, upgraded the hard drives in the newer models, and updated the antivirus software across the board. The resulting change in user experience was extraordinary without making any changes to the customer's Exchange implementation.

This example is applicable for customers moving to Exchange Online in Office 365. This service provides a 25 GB mailbox for a very low price point. In versions prior to Outlook 2013, the cached .ost file would generally settle on being roughly twice the mailbox size. In the previous case, that would mean that Outlook 2010 would require roughly 50 GB of local disk space on the client machine to cache a full 25 GB mailbox. Outlook 2013 contains two features to help with this issue: First, the .ost file structure has been engineered for improved compression to avoid file growth over time. Second, you can control the age of items that are stored in the local cache via a slider within Outlook.

Smaller Ultrabook-style laptops are now very popular. Their solid-state drives (SSD), however, often have a relatively small capacity—128 GB is commonplace. This means that an end user may run out of physical disk capacity on their laptop before they reach their mailbox quota, which is indeed a very poor user experience!

Supportability

Supportability can be split into two areas. The first is manufacturer support, such as Microsoft providing support for Outlook. The second area is the ability of support personal to operate and troubleshoot the product, such as the local help desk staff's ability to troubleshoot Outlook connectivity issues. For the purposes of this section, we will concentrate on manufacturer support, since the help desk support function is unique to each environment.

Outlook

Outlook has been the primary quality client for Exchange Server since Outlook 97. Every new release of Microsoft Office includes an updated version of Outlook that makes the best use of the latest Exchange Server features. This development cycle has made Outlook the most common email client in use in business today by far.

Nonetheless, with each new release of Outlook, the testing matrix for Exchange has grown. To combat this problem, the Exchange team made the decision starting with Exchange 2007 to discontinue support for older versions of Outlook. For example, support for Outlook 2000 was discontinued with Exchange Server 2007, and support for Outlook 2002 was dropped in Exchange Server 2010. This meant that it was necessary to know which client versions were installed in an organization and which client versions were supported for the version of Exchange that you were deploying. For Exchange Server 2013, the following versions of Outlook are supported:

Outlook 2013
Outlook 2010 SP1 + April 2012 CU
Outlook 2007 SP3 + July 2012 CU
Entourage 2008 for Mac, Web Services Edition
Outlook for Mac 2011

The most notable absence from this list is Outlook 2003. This version is still fairly common. Therefore, as part of your Exchange 2013 deployment planning, you should include client inventory and potentially a client upgrade program to remediate unsupported Outlook 2003 clients.

Let's move on to one of the most difficult problems to solve. Some customers have invested significant time and money in Excel and Word macro development. Legacy macros were written in Visual Basic for Applications (VBA). VBA was enhanced with each new version of Office and other Microsoft applications. This can sometimes place Exchange projects in sticky situations where customers need to upgrade the Outlook client for Exchange support. Moreover, upgrading Outlook generally means upgrading the entire Microsoft Office system, and this falls right into the critical path of the Exchange design and deployment project.

There are a couple of options available for solving the Outlook upgrade problem. First, it is possible to install a newer version of Outlook next to an older version of Office. Outlook 2007 with Office 2003, for example, allows a customer with an old desktop installation to migrate to Exchange Server 2013 without having to upgrade the entire Office suite at the same time. This does have its downsides, however. For example, Outlook uses the installed version of Word for various enhanced editing functions. Mixing versions of Outlook and Word results in the loss of automatic spell-check in the Outlook editor, though manual spell-check is still available.

Another option is to use Outlook Web App instead of Outlook. The problem with OWA is that it does not provide the same feature set or user experience as Outlook connected via MAPI or Outlook Anywhere. Most notably in OWA in Exchange 2013, you cannot access public folders or use S/MIME certificates. In addition, there are the usual problems of not being able to access .pst files. Nonetheless, for some users, this may represent a better option than running a different version of Outlook and Office on the same system. Of course, the ideal solution is when the customer upgrades to Office 2013 and has their macros rewritten as necessary.

Outlook Web App

Browser support is slightly more complex in Exchange Server 2013 than in previous versions due to the introduction of OWA Offline Access and the removal of spell-check from OWA, relying instead on browser-based spell-checking. All of this along with varying browser behavior depending on operating system makes for a number of situations. Table 12.1 shows the relationships among browser, client, and OWA features in Exchange Server 2013.

Table 12.1 OWA feature availability by operating system and browser:

POP/IMAP

There is no specific Exchange support statement for POP3 and IMAP4 clients from Microsoft. The only thing regarding these clients that you need to be aware of is that, by default, both are disabled in Exchange Server 2013. To enable POP3, you must start the Microsoft Exchange POP3 service and the Microsoft Exchange POP3 Backend service. To enable IMAP4, you must enable the Microsoft Exchange IMAP4 service and the Microsoft Exchange IMAP4 Backend service. For individual client support, contact the vendor of that client.

Exchange ActiveSync Devices

The EAS protocol version is linked to the Exchange Server version. The latest release of EAS at the time of this writing is version 14.1, which was last updated in Exchange Server 2010 SP1. Exchange Server 2013 and Exchange Server 2010 SP1 both use EAS 14. This means that any EAS clients that were supported in Exchange Server 2010 SP1 are also supported in Exchange Server 2013.

By far the biggest problem with EAS clients is determining just how many EAS features are implemented on each device. The most comprehensive listing of EAS feature implementation by client is found at the following address. Nonetheless, some important client devices, such as Windows Phone 8 and later Apple iOS versions, are missing from this list:

http://en.wikipedia.org/wiki/Comparison_of_Exchange_ActiveSync_Clients

To offer any valid level of assurance that certain devices will provide specific features given the random behavior of EAS devices, it is imperative that you test them explicitly to be sure.

CDO and MAPI

As we have discussed, many third-party systems connect via CDO and MAPI. We also noted that Exchange Server 2013 would require a new version of CDO to connect. What we did not mention was that manufacturers will often specify a preferred version of CDO for each version of their product and Exchange Server to ensure the best level of service.

We suggest that you ask your vendor to recommend a version of CDO to use in these circumstances. They will know best which problems they have tested for that other customers have experienced. Never assume that simply using the latest version of CDO will provide the best experience.

Regulatory Compliance

Compliance is a term often used during Exchange design and deployment projects. Regula-tory compliance is basically the data control processes that an organization must follow in order to conform to the necessary laws and regulations that govern its business.

Compliance legislation varies by country. In the United States, the Sarbanes-Oxley Act of 2002 (SOX) is the legislation cited most often that impacts Exchange. In the United Kingdom, the Data Protection Act of 1998 applies to every organization. In Canada, the Keeping the Promise for a Strong Economy Act (known as C-SOX) of 2002 applies.

These pieces of legislation have many areas in common. Most enforce rules for data retention, confidentiality, and the release of information. It is also worth noting that many organizations will add their own compliance polices to maintain reputational integrity and to secure sensitive data. These policies may state that the end user's device must be company owned or that certain data on mobile devices must be encrypted.

It is important to understand what legislative compliance requirements apply for each customer and where the design will meet them; that is, on the Exchange server side or client side. Many of the legislative compliance requirements can be met by using journaling at the server side. Journaling keeps a digital record of every email communication between users, both inside and outside the organization. The client is generally not aware of this process, and even if the client deletes content, it will remain in the journal repository until such time that it is deleted.

Organization Security Compliance

For organizational compliance requirements such as protecting against data leakage, the issues become more complicated. For example, many organizations wish to control where their data is stored and accessed. This control may include statements such as “mobile devices must have a passcode,” “mobile devices must be encrypted,” or “only company-provided devices are allowed to connect to the company email system.” Such controls often provide the largest hurdles to design teams.

We have already discussed EAS and that although the protocol includes many security policies, the vendor of the device chooses how these policies are implemented. This means that some devices may report that they have met all of the security policy requirements when in fact they have not. This was very common in early Android devices, although most devices today are pretty good in this regard. Additionally, controls to prove that a device is indeed company owned may bring with them complex and expensive dependencies, such as IPSec deployments or certificate-based authentication.

Organizations may even enforce two-factor authentication (2FA) for system access. 2FA indicates the control of system access by requiring two bits of authentication data. For example, your username and password plus a security token or smartcard is two-factor authentication. A 2FA system is perceived as being more secure than a single-factor scheme, such as a simple username and password security system, but it obviously brings with it more complexity. Most significant from an Exchange client perspective, many common clients, such as Outlook, do not support 2FA particularly well, if at all.

Given all of this doom and gloom, how should you best meet these security requirements while simultaneously not incurring a huge expense or making system access too difficult for end users? The most common answer to this question is to use information rights management (IRM). IRM works by digitally encrypting and controlling end-user rights at the time the document or message is created. These controls allow variations in end-user permissions such as read-only, do not forward, block copy and paste, and disable print. The end user must authenticate to the IRM service, which in turn will provide the information required to decrypt the message and enforce the granted rights. Using IRM provides many benefits, both internally and externally. From an Exchange client perspective, the most important benefit is that as long as your client is capable of viewing the IRM protected documents, you no longer need to provide client-side access controls.

As a general rule, do not attempt to control data leakage via perimeter controls and device access solutions. Use an IRM product instead, such as Active Directory Rights Management Services from Microsoft.

Performing a Client Inventory

At the beginning of a project, we typically ask for a list of client types that must be supported by the end solution. There are generally two responses to this question: Either the customer responds quickly and confidently with such a list (accurate or not) or we get a look that tells us no one has considered this question previously.

Since we now recognize the importance of client choice, it should come as no surprise that we strongly recommend that you try to determine which client types are used on the existing service before you attempt to design a new one. This recommendation is equally applicable if you are moving to Exchange Online, which is part of Office 365. Client type has a dramatic impact on network and other system resources. If you cannot reasonably assess the client types/versions that will use the service, it could prove to be very difficult to ensure that the service meets all of its requirements.

Messaging API (MAPI/RPC)

By far the easiest way to determine the types of MAPI clients that are connected to a system is via the Exchange Client Monitor (ExMon). While this tool has not yet been released for Exchange Server 2013, at the present time the most important use for it is on an existing Exchange service to get a better understanding of client types within the environment to help with the Exchange 2013 design.

ExMon is a great tool, but it is known to crash frequently. If it does indeed crash, the background ETL trace should continue to run. You can see this by looking for the state of the Exchange Event Trace via logman, an example of which is shown in Figure 12.1. Logman is a command-line tool that manages performance counter and event trace log collections on both remote and local systems.

Figure 12.1 Logman query results for ExMon trace

If the Exchange Event Trace shows a status of Running, the trace file is still being created and will stop logging when it reaches 512 MB. If you want to stop the trace before then, you can do so via the following command:

logman stop "Exchange Event Trace" -ets command

By default, the ETL trace file will be stored in the default directory C:\Program Files (x86)\Exchange User Monitor. To open the ETL file, simply drag it over the ExMon.exe file in File Explorer. It is beyond the scope of this section to walk through the ExMon output in detail, but it is explained quite well in the following TechNet article:

http://technet.microsoft.com/en-us/library/bb508855(EXCHG.65).aspx

For the purposes of client inventory, it is recommended that you run a few traces during a workday and then export that data to a .csv file for analysis within Excel. The aim of this process is to determine which Outlook client versions are currently in use so that you can ensure that your new Exchange 2013 solution will work with them or that they can be identified and upgraded.

Linux MAPI Clients

A word of warning here about Linux MAPI implementations: The Linux MAPI library allows Linux mail clients, such as Evolution, to connect to Exchange 2007 and Exchange 2010 via MAPI. These clients usually report in ExMon as version 12.0.6206.1000, which is the same as Outlook 2007. The problem with this procedure is that Exchange 2013 does not work with any current Linux MAPI implementation, and so all of these Linux MAPI clients will fail to connect if you migrate them over to Exchange Server 2013 without first reconfiguring them back to IMAP4 or POP3. You first must identity them, however, which is tricky since you can't tell them apart from Outlook 2007. If you have a significant population of Linux users, it's probably a good idea to notify them of this issue prior to migration.

Web Clients (EWS, EAS, and OWA)

Exchange Server uses the standard-issue Internet Information Server (IIS) to serve web requests, both HTTP and secure HTTPS. There is no easy way to see how many of each version of the web client requests are being made to Exchange Server. This information, however, is tucked away in the IIS logs.

Log Parser is by far the best tool for analyzing text logs generated via IIS. There is a great write-up of this tool specifically for Exchange on the Exchange Team Blog:

http://blogs.technet.com/b/exchange/archive/2007/09/12/3403903.aspx

We recommend spending some time analyzing the data from your Exchange Server IIS logs and grouping the results into device categories. This will help you to quantify the relative size of each device group and allow you to understand the importance of each device type and version. See the end of this section for a link to some scripts to help with this.

POP3 and IMAP4

Since neither POP3 nor IMAP4 has changed recently, it is unlikely that you will need to know the precise client versions deployed for your design. One thing you do need to know is how many POP3 and IMAP4 clients there are in the organization, because potentially you may not need to support POP3 or IMAP4 clients at all.

The easiest way to understand POP3 and IMAP4 usage within an existing Exchange environment is to log some Exchange performance counters over a period of time. We recommend logging the following performance counters every 15 minutes for a couple of weeks:

\MSExchangeIMap4\Active SSL Connections
\MSExchangeImap4\Current Connections
\MSExchangePop3\Active SSL Connections
\MSExchangePop3\Connections Current

Once you have a better understanding of the scale of POP3 and IMAP4 usage, you can then decide if you need to take things further. If there is significant usage in the user population, then you should include POP3 and IMAP4 appropriately in your design. If you are dealing with a very small community of users who rely on these protocols, this may be a good time to move them over to an alternative protocol, such as OWA or EWS.

To enable protocol logging, use the following commands:

Set-PopSettings -Server "CAS1" -ProtocolLogEnabled $true -LogFileLocation "E:\POP3Logs"
Set-ImapSettings -Server "CAS1" -ProtocolLogEnabled $true -LogFileLocation "E:\IMAPLogs"

Warning

IMAP4 and POP3 protocol logging can consume considerable disk space on heavily used servers. Make sure that you specify a log file location with plenty of space, and remember to disable protocol logging when you have finished.

Analyzing these logs should provide sufficient information about the users who are authenticating to the mailboxes and also the client device IP addresses. Such information should be sufficient to locate the individual users and have a conversation with them about their client usage.

Here is a short example from a POP3 protocol log. This log shows both the client IP address and username that was used for authentication.

2013-03-12T15:11:40.765Z,0000000000000002,2,192.168.15.101:110,192.168.15.100:51632,,5,20,5,user,jenson@org7.lab,R=ok

When performing this process, it is important to remember that the fewer client types and protocol mechanisms that your Exchange design needs to support, the simpler it will be. Additionally, it reduces the attack surface of the solution, which is always a good thing.

Scripting

All of this log file analysis is great. But if you have lots of Exchange Servers, or you are just not comfortable with LogParser, then there is still some hope. Our friend Steve Goodman has created a couple of scripts that will analyze your IIS logs and generate a nice report.

The scripts can be found here:

http://www.stevieg.org/2011/04/how-to-get-info-about-your-activesync-ews-and-webdav-clients-before-migrating-to-exchange-2010/

Design Considerations

As we have discussed, clients offer a varying range of features and thus they have a varied range of requirements and dependencies. Client choice can be both a solution to a design requirement and a design requirement in their own right. An example of this might be that a customer has deployed Outlook 2007 and for some reason cannot upgrade. Thus Outlook 2007 becomes a design constraint; that is, regardless of any other requirements, the solution must support Outlook 2007. In contrast, consider a customer who has a widespread use case that is satisfied only by a new feature within Outlook 2013. Then the use of Outlook 2013 becomes a design decision that satisfies a requirement.

Supportability

Supportability of the client is clearly important, but it is often not viewed strategically. In an ideal world, the version of Outlook and Exchange should be from the same release wave. This would mean that a customer would pair Outlook 2010 and Exchange 2010 or Outlook 2013 and Exchange 2013. One reason for this suggestion is that these products were developed together and will provide the best feature set and end-user experience. Additionally, the support life cycle is likely to be well matched in that both client and server will be at the same support life cycle phase.

As mentioned previously, Outlook 2003 is not supported with Exchange Server 2013. Many customers currently use Outlook 2003 with Exchange Server 2010. If you spend some time on support forums, you will see that many customers are experiencing performance problems with this configuration, especially if Outlook is in online mode. Switching to Outlook cached mode or changing the MSExchangeRPC polling interval on the Exchange 2010 server can help, but be aware that if you have a significant mismatch in client release version and Exchange release version, you may run into difficult-to-resolve problems.

As a general rule, the best design is the most common one. We often have discussions with customers about “the art of the possible.” However, the reality is that, for most customers, you should deploy a solution that is based on common components and software. The main benefit of this is that whenever an update is released, it is highly likely that someone on the technical adoption program shares a similar environment, and so bugs will be caught before you get the update.

The bottom line is that when making decisions about client versions, you do not want to be the exclusive user of a specific client version with Exchange Server 2013. Stick to the well-trodden path to avoid problems. Also remember that clients have support life cycles as well. As an example, Outlook 2010 was first released in July 2010. It is in mainstream support until October 2015 with extended support running until October 2020. Extended support means that the product receives critical security fixes only and that there will be no feature development and limited updates.

You can check Microsoft client version support at the following address:

http://support.microsoft.com/gp/lifeselectindex

Although Outlook is most likely to be the primary interface between end users and an Exchange service, do not forget about browser support for the Outlook Web App and Exchange Administration Center (EAC). As mentioned previously, browser support has changed with Exchange 2013. Many customers still have older browsers installed, such as Internet Explorer 7, which are not supported in Exchange Server 2013. Also make sure that the customer's browser will support any features that you need to provide in OWA. This is especially important if you intend to make use of new features such as OWA offline mode.

Security

Security is a broad topic and is covered in detail in Chapter 8, “Securing Exchange.” From a client perspective we are usually interested in the areas of connection encryption, data encryption, and authentication.

Connection Encryption

Connection encryption is the use of encryption technology to secure communication between two or more computers. Typically, an encrypted connection will make use of Public Key Infrastructure (PKI) to issue certificates, which are used to encrypt and decrypt data.

Clients create network connections to the server, typically over TCP/IP. One of the most common requests from security teams is to ensure that all client traffic is encrypted when passing over untrusted networks such as the Internet. When making design decisions, it is important to consider how your clients will meet these requirements. For example, some POP3 and IMAP4 clients can only create an encrypted secure sockets layer (SSL) connection if the encryption certificate has the uniform resource locator (URL) name at the top of the list of subject alternate names (SAN), or it is the only name on the certificate. Many design teams do not consider this when planning their certificates, and they end up having to request a new certificate just for POP3 and IMAP4 clients. Our advice is to ensure that you analyze encrypted client connectivity in your design test lab to ensure that your proposed certificate and name spaces will work with your clients.

Data Encryption

Data encryption refers to encrypting data sent between computers; that is, rather than encrypt all communications as with connection encryption, only the data that needs to be securely transmitted is encrypted. This is often used in combination with connection encryption to provide a robust and secure communications mechanism. Typically, the certificates used to create the secure sockets layer connection encryption and the email body encryption will be different, and so an individual would need to breach both layers of encryption and get both certificates before they could read the contents of the email message.

There are many ways to encrypt message contents, ranging from simple password protection of a Microsoft Office document or compressed Zip file to encrypting the entire message body with secure MIME (S/MIME). Attaching an encrypted attachment to the message only protects the attachment. Thus if someone is able to intercept the email message, they are still able to view the message body and any text that is in it. S/MIME encrypts the entire message body, and so it protects both the attachment(s) and message content. Not all clients, however, support S/MIME, whereas virtually all clients allow an encrypted attachment to be sent.

Additional levels of security can be provided through information rights management (IRM). But not all clients support IRM, and those that do often provide varying IRM feature levels. Again, our recommendation here is that your design test lab include an implementation of your proposed IRM solution so that you can validate client behavior.

Authentication

Authentication is the process of identifying yourself to the messaging service so that it knows to which mailbox to provide you access. Unfortunately, network authentication credentials suffer from exactly the same problems as real-world credentials; that is, if an ill-intentioned individual gains access to them, that individual can impersonate the user to whom the credentials apply and access their data.

The simplest form of authentication is providing a username and password in plain text to the server. As discussed earlier, this was very common with early Internet protocols, such as POP3 and IMAP4. Most enterprise customers, however, do not relish the prospect of their username and password being sent unencrypted over a network for someone to view with a freely downloadable application, such as Wireshark or Microsoft's Network Monitor.

To protect plain-text credentials from being viewed via a network monitor, you can encrypt the network connection via secure sockets layer (SSL), as discussed in the “Connection Encryption” section. This process works by using certificates to establish an encrypted connection prior to sending the credentials. This does not prevent an ill-intentioned person from capturing the credentials from the network, but it makes what they manage to capture a lot less useful by encrypting it with the same level of security that online commerce companies and banks use to secure their transactions. It's a bit like stealing a safe but not being able to get at what's inside. This mechanism is used in many scenarios, such as Outlook Anywhere where MAPI is used to connect to Exchange via SSL, and also for secure POP3 (POP3S) and secure IMAP4 (IMAP4S).

Many organizations are concerned not only with the identity of the end user but also with the identity of the device. This brings with it a separate set of challenges, especially for mobile devices. A common solution to this requirement is to use certificate-based authentication. This process uses a certificate to prove identity. For mobile devices, this certificate replaces the requirement for a password (with the exception of first configuration). The connection between the device and the server is encrypted and then the certificate is sent to the Exchange server as proof of identity. This solution is very robust, but it does require that the organization have a well-deployed PKI and the ability to deploy certificates to both end users and mobile devices.

Client Performance

Design teams are typically concerned with two aspects of client performance. First, they are concerned with the performance of the client itself from the end-user perspective. This makes up a huge part of the user experience, and it should not be overlooked. Microsoft was very cognizant of this fact during the development of Windows 7 and Office 2010, and these design principles were carried forward to Windows 8 and Office 2013. If the client performance is perceived to be slow by the end user, it doesn't matter what you did with the Exchange service—the perception is simply that “Exchange is slow.”

Second, the client choice has a performance impact on Exchange Server. Some clients, such as MAPI or POP3, are extremely light when it comes to using Exchange system resources, while others are much heavier, such as Outlook Web App or IMAP4. Table 12.2 was derived from a fantastic white paper released by Microsoft for Exchange Server 2010. It compares client types and their resource usage in Exchange Server 2010. This data is not yet available for Exchange Server 2013, but it is included here for comparison purposes between the client types and to highlight the differences that client choice can have on server resource usage.

Table 12.2 CPU usage for Exchange 2010 Client Access role

Client	CPU (MHz/User)
Exchange ActiveSync (delta)	1.60
Exchange Web Services (Entourage)	0.71
IMAP4	0.86
Outlook	0.35
Outlook Anywhere	0.80
Outlook Web App	0.86
Outlook Web App in Exchange 2010 SP1	1.17
POP3	0.33

http://technet.microsoft.com/en-us/library/ff803560(v=EXCHG.141).aspx

Outlook provides some useful information that helps you determine the source of performance problems. The Outlook Connection Status dialog, as shown in Figure 12.2, can be viewed either by starting Outlook using the /rpcdiag switch or by Ctrl+right-clicking the Outlook icon in the taskbar. This dialog reveals details about each logical connection to your Exchange Server, including RPC response latency information.

Figure 12.2 Outlook Connection Status dialog

There are three columns of interest here: Avg Resp, Avg Proc, and Version. Avg Resp is the average response time from the server, including network latency. Avg Proc is the time that Exchange spent processing the requests. Version is the version of the Exchange server that processed the request.

Figure 12.2 shows an example from my mailbox, which is connected to Exchange 2013 in Office 365. I am located in England, and my mailbox is hosted in North America. You begin by finding the line with the highest Req/Fail value and then pick the values for Avg Resp (167 ms) and Avg Proc (11 ms). These values tell you that Exchange has dealt with my requests on average in 11 ms. If you subtract this value from the Avg Resp value of 167 ms (167 ms - 11 ms = 156 ms), you can see that the network latency between Exchange and me is 156 ms on average. This is extremely useful when you are trying to determine if a poor user experience is caused by Exchange Server or by the network connection. If Avg Proc is less than 50, Avg Resp is less than 200, and the client is still experiencing poor performance, then the most likely cause is the client device itself.

Network Usage

Network usage for clients became a hot topic with Exchange Server 2010 and even more so with Microsoft Office 365. Exchange 2010 moved the client connection point to the Client Access Server, and that meant that, for the first time, most customers had to use a load balancer with Exchange Server. Load balancers are required to spread the client workload evenly across multiple Exchange Client Access Servers. They also handle directing clients to a functioning Exchange Client Access Server in the event of a server failure. To scale a load balancer effectively, you need to know how much network bandwidth it will need to handle at peak time. This is the same for Exchange Server 2013, although you can now use a layer 4 load balancer. However, you will still need to know how much bandwidth it will need to handle before you purchase it.

Cloud deployments on Microsoft Office 365 bring with them a similar challenge. Your design needs to define how much network capacity will be required to connect the clients to the service via the Internet. Since network capacity often has to be purchased in advance and can also have long lead times, it is extremely important to get this scaling right to avoid poor client experience or buying too fast an Internet connection. Yes, although you may believe that there is no such thing as “too fast an Internet connection,” remember that you are responsible for the budget and thus you need to determine the difference between too fast (very expensive) and too slow (poor user experience).

The easiest way to determine your client bandwidth usage is via the Exchange Client Network Bandwidth Calculator, available at the following address:

http://gallery.technet.microsoft.com/office/Exchange-Client-Network-8af1bf00

This calculator allows you to model various user profile and client type combinations. This calculator also accounts for time zones to accommodate users in different geographic locations and in different time zones so that they can share the same Internet connection or load balancer.

Figure 12.3 shows a bandwidth prediction made by the calculator. You can see that the prediction is not a simple curve—it is based on morning and afternoon logon peaks. In this example, which is for 53,000 light Outlook Anywhere 2010 users, the calculator predicts that the peak network usage will be 69.12 Mbits/sec at around 14:30 (2:30 p.m.). Knowing not only the peak value but also the usage curve is extremely important for network capacity planning since network links are frequently shared with other services. To plan adequately, the network team needs to know the quiet times as well as the peak times.

At the time of this writing, the Bandwidth Calculator has not been updated for Exchange Server 2013. It also does not include third-party clients such as BlackBerry OS, Good for Enterprise clients, or Apple iOS because of constraints enforced in the end-user license agreement for those devices. The biggest omission in the current beta is that it does not provide data for POP3 and IMAP4. But since the author of the calculator is also the author of this chapter, we can say with some certainty that both POP3 and IMAP4 will be added in the next version.

Figure 12.3 Network bandwidth prediction

Exchange 2013 User Throttling

User throttling was introduced in Exchange Server 2010. The fundamental idea behind user throttling in Exchange Server is to prevent users from consuming more than their fair share of system resources. This is intended to prevent a denial-of-service attack and to promote fairness. If one user is using more than their fair share of resources, then they may experience a poor user experience. However, the rest of the users on the system will be protected from their misuse because of user throttling.

One question that we are often asked when discussing client scaling with customers is why didn't user throttling protect Exchange from the iOS bug in Apple iOS 6? (iOS 6 shipped with a bug in the way the client handled recurring meetings, which caused a continuous synchronization loop.) The answer is that user throttling in Exchange Server 2010 was intended to protect the system from a small subset of users monopolizing system resources. If a large number of users set out to monopolize system resources, the system just gets busier and busier until throttling simply cannot protect it any further.

User throttling in Exchange Server 2010 tracked three parameters: PercentTimeInCAS, PercentTimeInAD, and PercentTimeInMailboxRPC. When a user needed to be “backed off,” Exchange Server 2010 would issue a delay or deny access to the user, depending on the protocol in use. This often led to a very poor experience and potentially even an error being displayed on the client device. Our observations with Exchange 2010 suggest that the resource usage limits were possibly set too high and the back-off penalties were too severe. This meant that clients that hit the throttling limit were likely to have a poor user experience, but also that the throttling process did not protect the Exchange Server from misuse as well as it should have.

Exchange Server 2013 improves user throttling in a number of ways. First, it simply tracks the amount of time that a user spends in the server, that is, processing time. Second, the model for resource utilization is based on a token bucket. This model works like a monthly salary; that is, you are given some resources on a schedule and, if you use all of your resources too quickly, the system will begin to throttle your connection until your next “paycheck” when you will get some more resources. This model allows for client bursts to take place quickly and without penalty, but it will still control overuse by rogue clients. Third, the delays applied by the user-throttling process are now much finer (micro-delays). The delay applied to the user increases proportionally to the deficit of the user, namely, the larger the resource overuse, the larger the delay. Once the user reaches the CutOffBalance, Exchange Server will begin to reject the user's requests. However, the client would have to be performing very badly to reach this point.

Summary

As you have seen in this chapter, Exchange Server clients vary considerably. The reality of most deployments is that your primary client will be some version of Outlook, and this is where you should focus your efforts. Ultimately, you must make sure that the most common client receives the desired user experience. In addition to Outlook, Exchange Server ActiveSync is almost a given for most deployments because of the pervasive use of EAS in mobile devices such as Apple's iPad, Microsoft's Surface tablet, and a variety of smartphones. BlackBerry devices are still relatively common, but our experience is that most organizations are looking to phase out this infrastructure.

Remember that the clients in use may need to be upgraded or replaced to support a new version of Exchange Server. Exchange Server 2013 does not support Outlook 2003, and so any installations of this version will need to be upgraded before beginning a migration to Exchange Server 2013. Although an Exchange Server upgrade can often be transparent to end users, if you need to replace or upgrade their mail client, it will indeed be noticed and not always positively. Our advice here is not to underestimate how big a job it can be to upgrade Microsoft Office or Outlook in a large enterprise. These projects can take years to complete, so be realistic in your Exchange planning schedules if you are planning this type of upgrade.

By far the most difficult client-related task when upgrading Exchange is identifying and managing application clients such as those based on MAPI CDO and Exchange Web Services. Not only is it difficult to identify mail-enabled applications, but they also often require upgrades between Exchange versions. Our advice here is to perform a client inventory by looking at the POP3, IMAP4, and IIS logs in addition to running some client tracing with ExMon. This inventory process should identify the different types of clients using the current system and help to highlight which ones will require upgrades.

Client performance makes up a huge part of the user experience. Client performance is dependent on the performance of every link in the chain, from the end-user device right through to the disk spindles that store the mailbox data. Poor performance in any of these areas is likely to lead to a poor user experience, which is what you are trying to avoid in your design process by scaling your Exchange servers effectively and validating with Jetstress. But don't forget the end-user client machines and network performance. It is surprisingly common to see customers complain of poor Exchange performance only to find out that the cause is actually the network or something awry on the end-user device.

Above all, we hope that this chapter has helped you to view clients as a part of your Exchange design process and not just as an afterthought. Throughout the design process, remember that the user experience provided by your solution is primarily determined by the type and behavior of the client that they use.