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.
1. 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.
2. Security
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.
