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) |
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:
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 [email protected], 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&exsvurl=1</EcpUrl-um>
<EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab& exsvurl=1</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=< IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
<EcpUrl-sms>?p=sms/textmessaging.slab&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.
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:
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, [email protected].
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.
|
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.
