Implementing Client Access and Hub Transport Servers : Understanding the Client Access Server (part 1)

The Exchange Server 2010 CAS role is an evolution of the same role in Exchange Server 2007. It still provides client access services for clients but now also includes clients that use MAPI clients (for example, Outlook 2007) and client-oriented services such as the Autodiscover service.

Clients can access their mailboxes using Messaging Application Programming Interface (MAPI), voice access, Hypertext Transfer Protocol (HTTP), RPC over HTTP, ActiveSync, Post Office Protocol (POP), or Internet Message Access Protocol version 4 (IMAP4). Exchange Server 2010 consolidates the client store access paths by folding in the last remaining client (MAPI) into the CAS server. Now all client access is mediated by the client access server, which thus lives up to its name.

There are seven client types, shown in Table 1. These seven client types connect to the CAS in various ways using various protocols, as shown in Figure 1.

Table 1. Client Types

Client	Protocol
Outlook	MAPI over RPC
Outlook Voice Access	RTP
Outlook Web App	HTTP/HTTPS
Exchange ActiveSync	HTTP/HTTPS
Outlook Anywhere	MAPI over RPC over HTTP/HTTPS
POP Client	POP3 (receive) / SMTP (send)
IMAP Client	IMAP4 (receive) / SMTP (send)

Figure 1. Client type connections to the CAS.

A CAS must exist in every Exchange Server 2010 organization and, in Exchange Server 2010, there must be a CAS in every AD site where there is a mailbox server. A best practice is to have a CAS in every Active Directory (AD) site, where AD sites represent contiguous areas of high bandwidth. Additional CASs can be deployed for performance and fault tolerance.

As indicated before, the CAS is used for the following clients and services:

• Outlook MAPI

• Outlook Anywhere

• Availability service

• Autodiscover service

• Outlook Web App (OWA)

• ActiveSync

• POP3 and IMAP

Basically, the CAS role handles the communications for all client access except for the voice access. Outlook Voice Access clients are essentially telephone access, which is handled by the UM role. Each of the client access methods supported by the CAS role is discussed individually in the following sections.

Outlook MAPI

In Exchange Server 2007, Outlook MAPI clients connected directly to the Mailbox role servers. In Exchange Server 2010, Outlook MAPI clients connect to the CAS role servers. This provides a consistent connection point and a single point to manage client access, performance, and compliance.

This is by far the most common access client because most Outlook clients in a company’s internal network are Outlook MAPI clients. Outlook MAPI is also sometimes referred to as Outlook RPC because RPC is the connection protocol.

Note

The Messaging Application Programming Interface (MAPI) is technically not a protocol but is rather a general framework. This is implemented as the Exchange Server remote procedure calls (RPC) protocol in Exchange Server 2003, 2007, and 2010. So, technically, the protocol used by Outlook clients is called Exchange RPC.

However, the term MAPI is used synonymously and more commonly in place of Exchange RPC.

Outlook MAPI is commonly supported by Microsoft Outlook 2007 and Microsoft Outlook 2003.

Outlook Anywhere

Outlook Anywhere is the Exchange Server 2010 name for the original RPC over HTTP feature in Exchange Server 2003. It essentially enables remote procedure calls (RPC) clients such as Outlook 2003 and Outlook 2007 to traverse firewalls by wrapping the RPC traffic in HTTP. This enables traveling or home users to use the full Outlook client without the need for a dedicated virtual private network (VPN) connection, which is frequently blocked by firewalls.

For security, the Outlook Anywhere protocol is always implemented with Secure Sockets Layer (SSL) to secure the transport, so it is actually RPC over HTTPS. This ensures that the confidentiality and integrity of the Outlook Anywhere traffic is protected.

Note

The idea of allowing RPC over the Internet is anathema to many organization’s security groups. In the past decade, a number of well-publicized vulnerabilities occurred in the native RPC protocol, which gave it a bad reputation.

With the evolution of the RPC protocol and the securing of the transport with SSL, the Outlook Anywhere feature provides as much security as Outlook Web App (OWA) or ActiveSync. Outdated security concerns should not prevent an organization from deploying Outlook Anywhere.

Outlook Anywhere is enabled by default in Exchange Server 2010, albeit with a self-signed certificate. It is important to decide the certificate strategy and install the correct certificate type to ensure seamless access for clients.

Availability Service

The Availability service is the name of the service that provides free/busy information to Outlook 2007 and Outlook Web App clients. It is integrated with the Autodiscover service (discussed in the following section) and improves on the Exchange Server 2003 version.

In Exchange Server 2003, the free/busy information was published in local public folders. In Exchange Server 2010, the Availability service is web-based and is accessed via a uniform resource locator (URL). The service can be load-balanced with Network Load Balancing (NLB) and can provide free/busy information in trusted cross-forest topologies.

The Autodiscover service provides the closest availability service URL to the client in the XML file. It does the following tasks for the Outlook and OWA clients:

• Retrieve current free/busy information for Exchange Server 2010 mailboxes

• Retrieve current free/busy information from other Exchange Server 2010 organizations

• Retrieve published free/busy information from public folders for mailboxes on servers that have versions of Exchange Server that are earlier than Exchange Server 2007

• View attendee working hours

• Show meeting time suggestions

The Availability service is installed by default on each CAS. Interestingly, there are no Exchange Management Console options for the Availability service. All interaction with the service is through the Exchange Management Shell.

Autodiscover Service

In previous versions of Exchange Server, profiles were a frequent source of headaches for administrators. The Exchange Server 2010 Autodiscover feature automatically generates a profile from the user’s email address and password. The service works with the clients and protocols listed in Table 2.

Table 2. Autodiscover Supported Clients and Protocols

Client	Protocol
Outlook 2007	MAPI (Exchange RPC)
Outlook Anywhere	Exchange RPC over HTTPS
ActiveSync	ActiveSync

The Autodiscover service provides the following information to the clients:

• The user’s display name

• Separate connection settings for internal and external connectivity

• The location of the user’s mailbox server

• The URLs for various Outlook features

• Outlook Anywhere server settings

Autodiscover is an evolution of the Exchange Server 2003 MAPI referral feature, which would redirect the user to the appropriate Exchange Server back-end server and modify the user’s profile. All that the users needed to provide was their alias and the name of any Exchange server. This was a useful feature if the location of a user’s mailbox would change from one server to another, as it would automatically redirect the user and permanently change the profile. This was a marked improvement over the Exchange 2000 profile generation, which would simply fail if the server or alias were not specified correctly. Any Exchange server would do, and the user could type their full name, the account name, or even their email address. However, in Exchange Server 2003, the user still had to enter the information to get access.

With Outlook 2007 and Exchange Server 2010, it gets even better. The user simply provides authentication credentials, and the Autodiscover service determines the user’s profile settings. Then, the Autodiscover function of Outlook 2007 configures the user’s profile automatically, basically filling in the information automatically. No manual entry of the server name or username is needed.

When the CAS is installed, a virtual directory is created in the default website on the CAS server. The CAS role also creates Service Connection Point (SCP) objects in Active Directory.

When a client is domain joined and domain connected, the Outlook 2007 client looks up the SCP records in AD. The client picks the one in its site or a random one if there is none in its site. It then communicates with the CAS and gets an XML file with profile information. The Outlook client consumes this XML file to generate or update its profile.

The Autodiscover service can also be used by Outlook Anywhere and ActiveSync clients over the Internet, which requires SSL for security. The Outlook 2007 client uses the domain portion of the Simple Mail Transfer Protocol (SMTP) address of the user to locate the Autodiscover service. When the client communicates with the Autodiscover service over the Internet, the Outlook 2007 client expects that the URL for the service will be https://domain/autodiscover or https://autodiscover.domain/autodiscover/. For example, for the user chrisa@companyabc.com, the Autodiscover service URL will be https://companyabc.com/autodiscover/ or https://autodiscover.companyabc.com/autodiscover/.

The Autodiscover service requires the CAS. The Autodiscover service also requires that the forest in which it resides has the Exchange Server 2010 AD schema changes applied.

The functionality of the Autodiscover service and the Autodiscover feature can be tested using the Outlook 2007 client. The steps are as follows:

1.	Launch Outlook 2007.
2.	Press and hold the Ctrl key, and then select the Outlook icon in the system tray.
3.	Select Test E-Mail AutoConfiguration in the menu.
4.	The email address should already be populated, so enter the user’s password.
5.	Uncheck the Use Guessmart check box.
6.	Click the Test button.
7.	Review the Results, Log, and XML tabs.

The log should show a series of three lines in the log with the text:

Attempting URL https://ex1.companyabc.com/Autodiscover/Autodiscover.xml found through SCP
Autodiscover to https://ex1.companyabc.com/Autodiscover/Autodiscover.xml starting
Autodiscover to https://ex1.companyabc.com/Autodiscover/Autodiscover.xml succeeded (0x00000000)

					  

This shows that the Autodiscover URL was identified from the SCP record in AD. The client then attempts the autodiscovery and is finally successful in the last line.

The XML tab shows (data shown next) the actual file that is returned by the Autodiscover service. This not only includes information such as the user’s server and display name, but also information such as the URLs for the Availability service, Unified Messaging server, Exchange Control Panel (ECP), and OWA:

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
 <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
 <User>
 <DisplayName>Rand Morimoto</DisplayName>
 <LegacyDN>/o=CompanyABC/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Rand Morimoto</LegacyDN>
 <DeploymentId>84834df8-edb1-4b31-8bd5-610b1f9b4633</DeploymentId>
 </User>
 <Account>
 <AccountType>email</AccountType>
 <Action>settings</Action>
 <Protocol>
 <Type>EXCH</Type>
 <Server>EX1.companyabc.com</Server>
 <ServerDN>/o=CompanyABC/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EX1</ServerDN>
 <ServerVersion>7380826D</ServerVersion>
 <MdbDN>/o=CompanyABC/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EX1/cn=Microsoft Private MDB</MdbDN>
 <AD>DC2.companyabc.com</AD>
 <ASUrl>https://ex1.companyabc.com/EWS/Exchange.asmx</ASUrl>
 <EwsUrl>https://ex1.companyabc.com/EWS/Exchange.asmx</EwsUrl>
 <EcpUrl>https://ex1.companyabc.com/ecp</EcpUrl>
 <EcpUrl-um>?p=customize/voicemail.aspx&amp;exsvurl=1</EcpUrl-um>
 <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&amp; exsvurl=1</EcpUrl-aggr>
 <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&amp;IsOWA=&lt; IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;</EcpUrl-mt>
 <EcpUrl-sms>?p=sms/textmessaging.slab&amp;exsvurl=1</EcpUrl-sms>
 <OOFUrl>https://ex1.companyabc.com/EWS/Exchange.asmx</OOFUrl>
 <UMUrl>https://ex1.companyabc.com/EWS/UM2007Legacy.asmx</UMUrl>
 <OABUrl>http://ex1.companyabc.com/OAB/542fc47a-c163-4af9-8491-d3ea54c52cd6/</OABUrl>
 </Protocol>
 <Protocol>
 <Type>WEB</Type>
 <Internal>
 <OWAUrl AuthenticationMethod="Basic, Fba">https://ex1.companyabc.com/owa/</OWAUrl>
 <Protocol>
 <Type>EXCH</Type>
 <ASUrl>https://ex1.companyabc.com/EWS/Exchange.asmx</ASUrl>
 </Protocol>
 </Internal>
 <External>
 <OWAUrl AuthenticationMethod="Fba"> https://ex1.companyabc.com/owa/</OWAUrl>
 </External>
 </Protocol>
 </Account>
 </Response>
</Autodiscover>

					  

This information is presented in a neater form on the Results tab, as shown in Figure 2. You can clearly see the Display Name, Protocol, Server, Login Name, and the various URLs.

Figure 2. Autodiscover Results tab.

Outlook Web App

The Outlook Web App (OWA) is the full-featured Exchange Server 2010 web-based client. It is a component of the CAS server role. This client enables a user with a web browser to access the Exchange Server 2010 infrastructure from the intranet or the Internet. This is done securely using HTTPS and is supported by a wide range of browsers, including the following:

• Internet Explorer (IE)

• Firefox

• Safari

In addition to the email, calendaring, tasks, notes, and file access features, Exchange Server 2010 includes a number of new features for the OWA client. These new features include the following:

• Conversation View

• Presence and IM

• UM Voice Mail

• Calendar Sharing

• SMS Message Synchronization

• Improved Searching and Filtering

• Favorites Folders

• Message Delivery Reports

• Mail Tips Information

• Rights Management

• Group Management

OWA uses forms-based authentication by default. This requires that users enter their credentials in the format “domain\username” and their password. A common issue in large organizations is that users might forget to enter their domain and fail their authentication, leading to unnecessary help desk calls. OWA forms-based authentication supports three different logon formats to enable the organization flexibility in the logon. The three logon formats follow:

• Domain\user name— This is the default logon format and requires the user to enter their domain and their username. For example, companyabc\chrisa.

• User principal name (UPN)— This enables the users to use their email address and the logon format. For example, chrisa@companyabc.com.

• User name only— This enables users to just enter their username to logon. For example, chrisa. This is the simplest option for the user, especially for organizations with only one Active Directory domain.

To set the logon format for User Name Only, do the following steps:

1.	Launch the Exchange Management Console.
2.	Expand the Server Configuration folder.
3.	Select the Client Access folder.
4.	In the top-right pane, select the CAS server to be changed.
5.	In the bottom-right pane, select the Outlook Web App tab.
6.	Right-click the website to be changed and select Properties.
7.	Select the Authentication tab.
8.	Select the User Name Only option.
9.	Click Browse to find the domain.
10.	Select the domain and click OK. The result should look like Figure 3. Figure 3. OWA Logon format setting.
11.	Click OK to save the settings.
12.	At the warning that IIS needs to restart, click OK.
13.	Open a command prompt on the CAS server.
14.	Run iisreset /noforce to reset IIS.

The OWA client now prompts for only the username, as shown in Figure 4. This makes the logon process simpler for users in organizations with a single domain name.

Figure 4. User Name Only Logon format in OWA.