- By Orin Thomas
Objective 1.4: Design Client Access
Client Access Servers (CAS) allow users to connect to their Exchange mailboxes, whether they are located on the same local area network or connecting remotely through Outlook Anywhere, VPN, Outlook Web App, or DirectAccess. When you are designing your organization’s CAS deployment, you need to ensure that for every site with a mailbox server you have at least one CAS. In this objective, you’ll learn about the factors you need to consider when creating a Client Access Server design for your organization. In Chapter 2 you’ll learn about how to configure CAS to provide these services to users on your organization’s network.
Planning Client Access Servers Location
The key fact that you need to remember when considering CAS placement is that you must place at least one CAS in every Active Directory site where there is a mailbox server. The greater the round-trip latency between the closest CAS and the mailbox server, the more degraded the experience is for clients accessing their mailboxes. You should also consider in your design the ability for CAS to function as proxies. This means that when a user who is in one site—for example, the Auckland site—is attempting to access his mailbox which is hosted on a mailbox server in a remote site such as the Wellington site, he will be able to use the CAS in the Auckland site to function as a proxy for the CAS in the Wellington site.
In earlier versions of Exchange, Outlook clients made a direct RPC connection to the mailbox server that hosted the appropriate mailbox. Exchange 2010 works differently in that the CAS functions as an intermediary, processing all client RPC requests. In an Exchange 2010 environment, the CAS interacts with the Mailbox server on behalf of the Outlook client. One of the most substantial benefits to this is that in the event of Mailbox server failure when Database Availability Groups are in use, the CAS automatically redirects clients to an available mailbox database.
CAS Proxying and Remote Access
The ability for one Exchange Server 2010 CAS to function as a proxy for another CAS will substantially influence your plans for an Exchange Server 2010 infrastructure. This is particularly useful when you have CAS and mailbox servers paired in sites that are not directly exposed to the Internet. For example, an organization may have CAS and Mailbox servers in the cities of Sydney and Melbourne, but only the Sydney CAS is exposed to the Internet. A user whose mailbox resides in the Melbourne site and who accesses OWA from the Internet would connect to the Sydney CAS. The Sydney CAS would then proxy that connection through to the CAS in the Melbourne site, rather than directly interacting with the mailbox server in the Melbourne site.
CAS Proxying not only works with traditional mailbox access through Outlook, but also works for access through Outlook Web App and Exchange ActiveSync. This technology allows you to provide access to Exchange for clients on the Internet by placing CAS on the perimeter network at a single site, knowing that CAS Proxying will ensure that those remote clients will be able to get access to the appropriate mailbox server.
Planning Client Access Server Services
When planning CAS deployment within your organization, you need to consider which services you want to offer. CAS provide the following services to an Exchange 2010 deployment:
Outlook Web App Allows clients to access mailboxes through their browser. Many organizations provide this service to allow clients a quick way of remotely accessing their mailboxes without having to use a dedicated client.
RPC Client Access Allows MAPI clients, such as Outlook 2010, to access mailboxes. This is the default way that Exchange mailboxes are accessed in most organizations through the CAS, primarily because organizations that are likely to use Exchange are also likely to use Outlook as their primary mail client.
POP3/IMAP4 Allows clients that don’t support MAPI, such as Windows Live Mail, to access mailboxes. As more and more clients support either MAPI or (in the case of mobile clients) ActiveSync, the use of POP3 and IMAP4 is decreasing on most organizational networks.
Outlook Anywhere Allows Outlook 2003 and later clients to access mailboxes through HTTPS. Outlook Anywhere can be used to allow remote mailbox access without granting DirectAccess or VPN access.
ActiveSync Allows mobile devices that use Exchange ActiveSync to synchronize mailbox information. This protocol is often used by consumer devices such as the iPad to access Exchange mailboxes.
Availability Service Provides clients with calendar free/busy information.
Exchange Web Services Allows programmatic access to Exchange functionality through XML/SOAP interface. Rarely used by most organizations for Client Access scenarios.
MailTips Provides users of Outlook 2010 and OWA with reminder information, such as whether the message recipient is out of office, or that they are sending to a distribution list.
Exchange Control Panel (ECP) A web-based interface that allows Exchange administrators to perform certain tasks such as performing searches of all organizational mailboxes for messages that meet a specific set of criteria.
Address Book Service Interface that allows address book queries.
Autodiscover Service that allows clients running Outlook 2007 and later and Windows Mobile 6.1 and later to be automatically configured based on user profile settings.
Most of these services are enabled by default. It is possible to disable them specifically on a per-CAS or per-user basis. Figure 1-13 shows these services disabled on a per-mailbox basis.
Exchange Control Panel
Exchange Control Panel (ECP) is a web-based control panel that, when accessed by a user, allows the user to configure items such as vacation settings, inbox rules, group management, password change, email signature, and spelling options. Users with administrative privileges can also use ECP to configured users, groups, roles, and auditing settings as shown in Figure 1-14. Users that have been delegated the Discovery Management role can use ECP to perform multi-mailbox searches.
Figure 1-13 Client Access Server services
Figure 1-14 Exchange Control Panel
Exchange ActiveSync allows the syncing of Exchange mailbox information—including messages, calendar, and contact data—to mobile devices such as phones and tablets. ActiveSync supports a technology known as DirectPush. DirectPush allows the mobile device to maintain a persistent connection to Exchange, meaning that new messages are received in real time rather than according to a scheduled polling interval.
Exchange ActiveSync Policies, applied through the ActiveSync process on compatible devices, allow you to control the security of mobile devices. For example, you can use an ActiveSync policy to control password policies, whether to allow the use of hardware such as cameras, Bluetooth, or removable storage usage; whether to support remote-device wipe; and which applications can be executed on the device.
You would plan the use of ActiveSync policies in your Exchange Server 2010 infrastructure if you had specific concerns around mobile device security. You will learn more about ActiveSync policies and how they can be used to improve information security in Chapter 3, “Designing and Deploying Security For the Exchange Organization.”
Testing Client Access Server Performance
Administrators can use the Load Generator (LoadGen) tool to plan an Exchange Server 2010 deployment to determine how well a CAS infrastructure performs under a simulated client load. By using this tool you can assess whether you need more CAS, whether your planned deployment meets expectations, or whether you have overprovisioned the CAS role.
LoadGen is able to simulate the following types of client activity:
Microsoft Office Outlook 2003 (online and cached)
Outlook 2007 (online and cached)
Outlook Web App
You can choose whether to simulate a single-protocol workload or combine client protocols to determine how well the CAS infrastructure deals with a multi-protocol workload. Using LoadGen you can also calculate client computer response time when CAS are under a specific load, estimate the number of users that each CAS will be able to provide services to concurrently, and identify hardware and design bottlenecks.
Client Access Server Hardware Requirements
Microsoft has done a substantial amount of research on Client Access Server capacity. You can reference this research in detail if you are interested in determining the relative weighting that you should give Client Access Server processor capacity in terms of the capacity of your organization’s Mailbox server. A rough summary of Microsoft’s finding is that you should deploy three Client Access Server processor cores in an Active Directory site for every four mailbox server cores, assuming cores of equal processing capacity. Exchange Client Access Servers will still function if you use a ratio that differs from this theoretically optimal one. The idea of this ratio is to give you an idea of what the optimal ratio is, so that you can figure out if the Client Access Server at a site might be a bottleneck in Exchange performance because it is under-resourced with processor capacity, or if you have overprovisioned the Client Access Server role with CPU capacity that will never be utilized.
The Autodiscover service simplifies the process of configuring Outlook 2007, Outlook 2010, and mobile devices. Autodiscover allows the automatic provisioning of a user’s profile given the user’s email address and password. Rather than having to configure all necessary settings, the user simply enters her email address and password into the email client and all relevant mail server settings are automatically provided to the client through the Autodiscover service.
Planning Site Affinity for Autodiscover
If your organization has a number of clients that move between sites, you may wish to configure the Autodiscover service to use site affinity. When you configure the Autodiscover service to use site affinity on the Client Access Server, clients using Outlook 2007 or Outlook 2010 will be provisioned with Autodiscover information from the closest Active Directory site. In some organizations with geographically dispersed branch offices, this can substantially improve the performance of Autodiscover.
Planning Autodiscover for Internet Clients
You can configure Autodiscover so that remote clients on the Internet can automatically provision profile settings by entering their email address and password. For example, by using Autodiscover and using Outlook Anywhere, a user who is connected to the Internet can fully configure Outlook by entering his email address and password. The main requirement for Autodiscover for Internet clients is that you have an SSL certificate that is trusted by the client computer’s operating system. If the majority of the clients that will use this service are using their own consumer devices, the simplest approach to ensuring that the SSL certificate is trusted by clients is to obtain the SSL certificate from a trusted third-party Certificate Authority.
Autodiscover in Multiple-Forest Environments
Autodiscover, when appropriately configured, supports cross-forest topologies. When Autodiscover is appropriately configured, a client that supports Autodiscover on a computer in another forest can be provisioned automatically by the local forest’s Client Access Servers. For example, Contoso might have a cross-forest topology in which one Exchange organization is in Australia and another Exchange organization is in New Zealand. When Autodiscover is configured to support the multiple-forest environment, a user that logs on in the New Zealand forest—but who has been configured with a mailbox in the Australian Exchange organization—will be able to have those Australia-based profile settings automatically provided to her client by providing her email address and password.
Planning Client Access Server Certificates
Server certificates, also commonly known as Secure Sockets Layer certificates, allow clients to establish a secure connection to a host that has a verified identity. This is very useful in CAS scenarios where a multitude of clients need to be able to use a CAS to securely access mailbox data through a variety of protocols.
Something that you must consider in your design is that unless you take specific steps to remedy the situation, Exchange defaults to using self-signed certificates created during the installation process. This is fine for communication between Exchange servers in the same organization because these servers trust these self-signed certificates. This is problematic for clients who are unlikely to trust these self-signed certificates without you performing remedial action. If a significant number of Exchange clients are going to be running computers that are not a part of your organization’s domain, you should consider obtaining an SSL certificate from a trusted third-party Certificate Authority (CA). Although these trusted third-party CA certificates do have a fee associated with them, the cost of supporting the deployment of a certificate issued from an internal CA to clients that aren’t members of a domain often exceeds the cost of obtaining the third-party certificate.
The key to planning the names assigned to certificates used by Client Access Servers is knowing the name that client will be using to access each required client protocol on the server. For example, you might be planning to have users connect to Outlook Web App using the address https://owa.wingtiptoys.com, to the POP3 server using POP.wingtiptoys.com, to Autodiscover using Autodiscover.wingtiptoys.com, and to IMAP4 using IMAP4.wingtiptoys.com. In this situation you need to ensure that the certificate you install supports all of these names. In this situation you can plan to take one of the following options:
Obtain four separate certificates, one for each separate name. This is the traditional option, although it can be more cumbersome to implement.
Obtain a single certificate that supports multiple subject alternative names (SANs). Getting a certificate that supports multiple SANs is usually the best option and almost all trusted third-party CAs will issue them more cheaply than they’ll issue multiple separate certificates. You have to perform a minor modification to a Windows Server 2008 R2 CA to configure them to support the issuance of certificates with multiple SANs.
Obtain a certificate with a wildcard name. These certificates are also supported by most public CAs. In the example situation you would configure the certificate with the wildcard name *.wingtiptoys.com.
Configure all services to use the same name, such as mail.wingtiptoys.com. This allows you to solve this problem by only needing to acquire a single certificate.
Include Outlook Anywhere in your design if you want to allow users remote access to Exchange without having to provision a VPN solution or DirectAccess. Outlook Anywhere is supported on clients running Outlook 2007 and Outlook 2010.
ActiveSync allows supported mobile devices to access mailbox data.
You can configure Autodiscover to automatically provision Outlook 2007 and Outlook 2010 clients. When properly set up and used in conjunction with Outlook Anywhere, Autodiscover can provision clients on the Internet.
You can configure Autodiscover with ActiveSync to automatically provision ActiveSync clients based on email address and password.
POP3 and IMAP4 can be enabled on CAS to support non-Outlook messaging clients that do not support ActiveSync or MAPI.
Subject Alternative Name (SAN) certificates allow multiple FQDNs to be associated with a single certificate.
The Load Generator (LoadGen) tool can be used to test a CAS against a simulated client workload.
Exchange Control Panel allows administrators to perform discovery and RBAC tasks. It allows normal recipients to perform tasks such as password change, group creation, and rules management.
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
You are in the process of evaluating a CAS deployment to determine whether it will be able to cope with a projected client load. Which of the following tools could you use to assist you in performing that evaluation?
Exchange Best Practices Analyzer
Exchange Remote Connectivity Analyzer
You are planning your organization’s Exchange Server 2010 deployment. Your current plans involve placing two mailbox servers at the Sydney and Melbourne sites and one mailbox server at the Adelaide, Brisbane, and Darwin sites. What is the minimum number of Client Access Servers that you need to deploy to support this configuration?
Tailspin Toys has its main office in Auckland and branch offices in Christchurch, Wellington, and Dunedin. The Auckland site has two mailbox servers. What is the minimum number of Client Access Servers that need to be deployed to support this configuration?
What is the theoretical optimum ratio of Client Access Server processor cores to Mailbox server processor cores in a single Active Directory site?
Three Client Access Server processor cores for every four Mailbox server processor cores
Four Client Access Server processor cores for every three Mailbox server processor cores
Two Client Access Server processor cores for every three Mailbox server processor cores
Three Client Access Server processor cores for every four Mailbox server processor cores
You want to ensure that Outlook 2010 clients get Autodiscover information from the closest Active Directory site. Which of the following steps should you include in your Client Access Server deployment plan to accomplish this goal?
Configure the Autodiscover Service for Internet Access.
Configure the Autodiscover Service for Multiple Forests.
Configure the Autodiscover Service to use Site Affinity.
Configure Exchange ActiveSync Autodiscover Settings.