Manage Learn to apply best practices and optimize your operations.

Part 1: The Exchange 2007 Client Access Server (CAS) role

Tutorial: A primer on Exchange 2007 server roles -- part 1 of 6.

The Client Access Server (CAS) role basically accepts connections from a variety of clients to allow them access to the Exchange Server infrastructure. To some extent, the CAS role has some similarities to the old front-end (FE) servers in Exchange 2000 and Exchange 2003.

Exchange 2007's Client Access Server accepts connections from:

  • Browser-based clients using either the full-featured Outlook Web Access (OWA) or a new OWA Light client
  • Mobile devices via Exchange ActiveSync (EAS)
  • Phone devices via Outlook by Phone
  • POP3 or IMAP4 clients, such as Outlook Express and Eudora

Exchange Server 2007 organizations running Exchange ActiveSync in conjunction with Windows Mobile 5.0 devices should consider installing the Messaging Security and Feature Pack on these devices in order to enable Direct Push. (Those of you familiar with BlackBerry devices and BlackBerry Enterprise Servers (BES) will recognize this as an obvious attempt by Microsoft to provide the same level of always-up-to-date email synchronization that BlackBerry users have enjoyed for the past 10 years.)

CAS also enables Microsoft Outlook 2007 clients to Autodiscover mailbox location from pretty much anywhere, as long as a CAS server is reachable. Essentially, a Microsoft Outlook 2007 client starts out looking at the email address of the user whose profile is being configured. For example, if the user is Aslan@narnia.na, then a Microsoft Outlook 2007 client on the Internet will check the DNS record for narnia.na for a CAS record published on the Internet (typically this would be done by publishing the CAS via Microsoft ISA Server or similar).

The Microsoft Outlook client would then authenticate against the CAS server, which in turn would use information from Active Directory and other sources to build an XML file based on the client's email address and logon identification. This XML file is passed back to the Microsoft Outlook client, which updates its profile with the correct information.

If the Microsoft Outlook client is not on the Internet, but rather on the corporate network, the process works somewhat differently. During CAS installation, a Service Connection Point (SCP) is created in Active Directory. When Microsoft Outlook 2007 connects to a domain, it automatically looks up the SCP records and tries to find one that is in the same Active Directory site. The Microsoft Outlook client then connects to the CAS server and -- in the same manner as the Internet-based Outlook client -- exchanges credentials for an XML file with all the information required to rewrite its profile.

While we're on the topic of client access, I should probably point out the difference between the premium edition of OWA and the new OWA Light. The premium edition of OWA includes features such as voicemail configuration, search, a browsable OWA address book, Windows SharePoint Services integration, file system integration, spellchecking and a Scheduling Assistant for booking meetings.

OWA Light drops most of these items and provides a simple, plain-text-only Web-based email client. I suspect that the Exchange Server hosting community had some involvement in driving for two different flavors of OWA -- this enables them to offer a low-cost basic Web client along with the opportunity to up-sell customers to a feature-rich Web-based client.

Figure 2
Figure 2: IIS virtual directories created by Exchange 2007

You'll see in Figure 2 that there are a number of new virtual directories created in Microsoft Internet Information Server (IIS).

  • The /owa directory is used by OWA clients connecting to Exchange 2007 mailboxes.

  • The legacy /exchweb and /exchange directories are used by OWA clients connecting to Exchange 2000 or Exchange 2003 mailboxes.

  • The legacy /public directory is used by OWA to gain access to public folders on Exchange 2000 or Exchange 2003 (public folders on Exchange 2007 are no longer accessible via OWA).

  • The /OAB directory includes two files, an OAB.XML containing metadata for Microsoft Outlook 2007 clients, and a number of .LZX files, which contain the Offline Address Book (OAB) in OAB v4 format.

As expected, Exchange Server 2007 does not bring back any of the features that we saw back in Exchange 2000 Server, which were dropped in Exchange Server 2003, including RVP-based instant messaging, chat, conferencing server or key management server. So if you still have any of those services in use, then you'll continue to need to keep an Exchange 2000 server around.

In an Exchange Server 2007 architecture, every Active Directory site that contains the Mailbox Server role also has to have a Client Access Server role installed, either on the same server as the Mailbox Server or on another machine. In addition, you'll want to have good network connectivity between the Client Access Server and Mailbox Server roles if they are on different machines.

Remember, Exchange Server 2007 totally rewrites the rules of message routing, and is now dependent on the Active Directory site topology for message routing (meaning you may need to clean up your Active Directory site topology as part of your Exchange 2007 deployment).

Once you get into your migration, you'll need to deploy a Client Access Server role first within each Active Directory site prior to actually deploying any other Exchange 2007 server roles in that site. Because of the heavy load you can expect to hit your CAS server, I recommend you deploy one CAS server for every two Mailbox servers if you are deploying them on separate servers.


TUTORIAL: A PRIMER ON EXCHANGE 2007 SERVER ROLES

 Home: Introduction
 Part 1: The Exchange 2007 Client Access Server (CAS) role
 Part 2: The Exchange 2007 Hub Transport Server role
 Part 3: The Exchange 2007 Mailbox Server role
 Part 4: The Exchange 2007 Edge Transport Server role
 Part 5: The Exchange 2007 Unified Messaging Server role
 Part 6: Server role Installation caveats and supporting information

ABOUT THE AUTHOR:   
David Sengupta, Microsoft Exchange MVP
David Sengupta (mailman@quest.com), based in Ottawa, Canada, is a Group Product Manager in Quest Software's Infrastructure Management group and a Microsoft Exchange MVP. He has contributed to Exchange Server books, magazines, and white papers; is a regular Exchange Server columnist and speaker; and speaks at Microsoft Exchange events, Tech-Ed and IT Forum conferences. .

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchSQLServer

SearchEnterpriseDesktop

SearchVirtualDesktop

Close