Blog Post

Exchange Team Blog
4 MIN READ

How Exchange Server 2007 CAS Proxying works for Outlook Web Access (OWA)

The_Exchange_Team's avatar
Sep 10, 2007

Continuing on my previous post, I wanted to go into explaining how Exchange Server 2007 CAS Proxying works for Outlook Web Access (OWA).

Proxying for Outlook Web Access is used when there is only one Internet-facing CAS Server. In this scenario the will be proxied to the CAS server where his mailbox server is located. This requires more intensive resource on the CAS server than doing redirection. The main benefit to this is your users can have a single point of access from external and proxying is transparent to the end user.

CAS-CAS Proxying is quite similar with the process described in the future topic "How CAS proxying works for ActiveSync". There are a few differences regarding the errors and logs.

Please see the following flowchart that will help you understand this process. To view the full version, please click on the thumbnail. We wanted to publish the flowchart in high resolution:

1. The First CAS queries the Active Directory to determine the location of the user's mailbox and the version of Microsoft Exchange that is installed on the Mailbox server. If the mailbox is on Exchange 2007, the First CAS will determine the best CAS, a Client Access Server in the same AD site as the user's mailbox server.

If the user's mailbox is on an Exchange 2003 server, the request will be proxied directly to the destination Exchange 2003 back-end server, even if there is an Exchange 2007 Client Access server within the destination Active Directory site. Windows Integrated authentication is required on Exchange 2003 /Exchange virtual directory.

Once is determined where the user mailbox is located, in this case on a Mailbox Exchange 2007 Server named Chicago.fourthcoffee.com. The First CAS has already made the decision to talk directly to a mailbox server in the same site, proxy the request to the Second CAS or return a web page link with the ExternalURL from the Second CAS where the user mailbox is located.

As the mailbox is on an AD remote site, the request is proxied to the Second CAS named Dallas.fourthcoffee.com.

2. If the First CAS itself is the best CAS for the request it will handle the request and initialize a mailbox session via RPC with the Exchange 2007 mailbox server. If it is an Exchange 2003 Server the communication will be via http(s) and Windows Integrated authentication is required on Exchange 2003 /Exchange virtual directory.

If there is a Client Access server that is closer to the user's Mailbox server, Exchange 2007 determines whether the Client Access server has the InternalURL property configured on /owa virtual directory Exchange and if the authentication method is Integrated Windows authentication. If so, the user is proxied to the Client Access server specified by the InternalURL property. Otherwise will return an error message to the client if could not find the best CAS.

Error: Outlook Web Access is not currently available for the user mailbox that you are trying to access. Please try again in a few minutes. If the problem continues, contact technical support for your organization and tell them the following: The available Microsoft Exchange Client Access servers in the target Active Directory site are not responding.

If the Integrated Windows authentication is not set on the Second CAS, it will return an error message to the client.

Error: Outlook Web Access is not available. If the problem continues, contact technical support for your organization and tell them the following: There is no Microsoft Exchange Client Access server that has the necessary configuration in the Active Directory site where the mailbox is stored.

3. The server hosting https://dallas.fourthcoffee.com/owa may be configured not to allow Kerberos authentication. It might be set to use Windows Integrated authentication for the Outlook Web Access virtual directory, but be configured to only use NTLM (not Kerberos) authentication for Windows Integrated authentication. See the IIS documentation for additional troubleshooting steps if you suspect this may be the cause of the failure.

4. If the best CAS has an "ExternalURL" set on the /owa virtual directory, than then First CAS will return a web page link to the client with the ExternalURL from the Second CAS.

5. When attempting to connect to a proxy request, if the Second CAS returns a HTTP_441 response, it indicates that the second CAS did not have the CSC for the SID that was passed. The First CAS will obtain the CSC, serialized into XML and issues a proxy login request.

Note: InternalURL is configured automatically during Exchange 2007 Setup. For Client Access servers that do not have an Internet presence, the ExternalURL property should be set to $null

6. The Second CAS initializes a new mailbox session to sync the user mailbox.

In next post: How Exchange Server 2007 CAS Proxying works for ActiveSync.

- Vandy Rodrigues

Updated Jul 01, 2019
Version 2.0
  • This might be a bit off topic, but we just brought our first exchange 2007 server online. We host Exchange and use Postini as our main smtp gateway so to start simple we are bringing 3 exchange 2007 servers with NLB online that have both the cas and hub

    transport role (edge will come later). Anyway, after installing the first cas / hub transport server I was unable to hit my exchange 2003 mailbox using the

    https://exchange2007server/exchange URL (received 404 page could not be found errors). I searched high and low for an answer and the only thing close was this article:

    http://support.microsoft.com/kb/932438


    but this is only when you have e2k7 cas + mailbox on one server trying to hit an e2k3 mailbox server. I saw one obscure post and did some digging to find out that our new exchange 2007 server was NOT added to the Exchange Domain Servers security group by default...

    why not? I manually added it into the group, waited a little for replication and then bam it started to work fine. Oh yeah, the installation also RESET our perms for domain admins at the Exchange organization level (I know, heaven's me, domain admins with

    "send as"...) and we had to manually remove the deny perms -- BES and Goodlink choked for while too.

  • That logins not going to work, and should be updated on the 446956 image example.  The user is not going to authenticate correctly as Fourthcoffee.com is the domain, not fourhtcoffee.com.

    Thanks,
    XPGoD
  • Is it possible to publish OWA of Exchange 2007 using Apache reverse proxy?
  • I have a question about the Integrated Authentication.  I read that in order to configure Integrated Authentication for OWA, the CAS has to be on an Exchange 2007 server by itself.  I read this at the following article:
    http://technet.microsoft.com/en-us/library/aa998638.aspx

    Does this mean that if we are using multiple sites and are going to do CAS-CAS proxying, that we won't be able to do proxying because our CAS is also our HTS?  We already have this fully configured and just noticed this today that in order for Integrated Auth to work, our CAS has to be by itself.

    Is this limitation only for when we are opening OWA and will get prompted with a username/password or does it apply both to that and Proxying?  I'm really hoping it's only for when user's go to OWA and will not affect Proxying.
  • Elan,

    CAS-CAS Proxying and Redirection work fine if installed on the same Exchange 2007 HTS. The article http://technet.microsoft.com/en-us/library/aa998638.aspx applies when you want to open OWA using Windows Integrated Authentication that enables the server to authenticate users who are logged on to the network without prompting them for their user name and password.
  • Well that's a huge relief.  Thanks Vandy.  I kind of figured this was the case as Redirection worked fine when we tested it.
  • Encountered the same issue as Gasp100: 404 when trying to login to OWA via a 2007 CAS server to a 2003 back-end (but it did work if the email alias was included at the end of the URL string). Event logs on the CAS server were filled with topology errors related to LDAP failures and inability to find the domain controllers. Added the new CAS server to Exchange Domain Servers group, and things worked like magic. What gives?
  • Same thing happened to me at a previous client Glen.  We were having topology errors all over the place and I added the Exchange Server (CAS/HTS/MB on 1 server) to the Domain Servers group and the Topology errors went away.  Not sure why that happened.
  • What are the pros and cons of using e2k7 CAS servers with e2k3 BEs? (The customer is not yet ready to upgrade the e2k3 BEs to e2k7 MBX servers.)
  • Based on your understanding of CAS redirection, could you please examine the following scenario and answer the question at the bottom.  Thank you.

    Two sites each with internet facing CAS and mailboxes.  External URL  for all internet facing CAS servers is the same: OWA.COMPANY.COM.   DNS round robin is used to load balance connectivity to the CAS servers at each location.

    If a user is DNS directed to the a CAS server in SITE_A but his mailbox is in SITE_B, it appears, based on the article, that the user would be redirected and given the internet facing URL of a CAS server in SITE_B.  However, since SITE_A and SITE_B both have the same internet facing URL, the user could get trapped since his DNS entry may not round robin because of a cached DNS entry.

    Is CAS smart enough to proxy this request since all external URL's are the same?  If not, can redirection be disabled and how?