Maintaining ActiveSync access to Exchange 2003 mailboxes after deployment of Exchange Server 2007 CAS role

EDIT: this post was edited on 9/25/2007 to clarify information related to the hotfix mentioned in KB 937031. Thanks to Vanitha for the edit!

As we mention in Exchange 2007 documentation, the first server role that should be upgraded when migrating to Exchange Server 2007 is the Client Access Server or CAS role. 

In order for your users to continue to synchronize their mobile devices via Exchange ActiveSync with their mailboxes hosted on Exchange 2003 mailbox servers, you will need to ensure that Integrated Windows Authentication is enabled on all of the Exchange ActiveSync virtual directories (Microsoft-Server-ActiveSync) on Exchange 2003 mailbox servers.

The following illustrates the process of how an ActiveSync user whose mailbox resides on an Exchange 2003 server gets to their mailbox through an Exchange 2007 CAS:

Steps to Enable Integrated Windows Authentication

Previously this authentication change had to be done using Internet Services Manager (ISM) because the authentication settings were grayed out in Exchange System Manager. However when the changes were made through ISM, the DS2MB process overwrote the settings in certain scenarios. A hotfix 937031 is now available to enable Integrated Windows Authentication using Exchange System Manager.

Steps to Enable Integrated Windows Authentication after installing hotfix 937031

1. Start Exchange System Manager, and then browse to the following location:

Server_name\Protocols\HTTP\Exchange Virtual server\Microsoft-Server-Activesync

2. Right-click Microsoft-Server-Activesync and then click Properties.

3. Click the Access tab, and then click Authentication.

4. Check Integrated Windows Authentication

You have already installed your CAS; how can you check if you have this problem?

On your Exchange 2007 CAS server, there are two indicators of the problem with proxying to Exchange 2003 servers due to authentication settings:

1. The application log of the CAS server will show event 1036 which will look as follows:

2. The IIS log on the CAS server will show the following:

2006-10-10 23:17:30 W3SVC1 OPTIONS /Microsoft-Server-ActiveSync User=e2k3user&DeviceId=6F24CAD599A5BF1A690246B8C68FAE8D&DeviceType=PocketPC& 80 flemby-dom\e2k3user MSFT-PPC/5.1.2000 401 5 0

- Michael Higashi

Comments (10)
  1. Mitchel W says:

    Checking my current Exchange 2003 config I see only basic authentication selected. Would it harm anything if I set it to both basic and integrated now in preparation for upgrade?

  2. Michael Higashi says:

    Hi Mitchel,

    If your topology has an Exchange "Front End" which mobile devices hit directly and a "Back-End" which is your actual Mailbox Server then having both Integrated and Basic Authentication enabled will not be a problem.  

    There will only be a problem if your "Front End" is on the same server as the Mailbox Server and this will impact Windows Mobile 5.0 MSFP devices or earlier .  

    Please let me know if you have any further questions.


  3. Max says:

    Is this picked up by exbpa?

  4. Exchange says:


    The BPA rule is coming soon.

  5. Del says:

    will a CA service a x7 mailbox server is a different AD site?  with x3 all our ISA and FE’s are in one AD site and service mailbox servers in many AD sites.  

  6. Andrew says:

    I read somewhere that the CAS server system is not supported in the DMZ.  Is that correct?  So if I need to provide users external access to CAS functionalities I have to either open a hole in the firewall or use ISA server?

  7. mike says:

    Hi Andrew,

    Yes, that’s correct, it is recommended not to place the CAS inside the DMZ.

    A best practice is to place the CAS on the internal network and have a reverse proxy direct traffic from the internet to the CAS.  ISA or other comparable products have the ability to publish CAS.  

    This Technet Article provides a good level of information to use ISA 2006 to publishing CAS (and other details related to Exchange 2007).

    Let me know if you have any questions.


  8. scathew says:

    The fact that the CAS isn’t within a sandwich of firewalls (ie: a DMZ perimeter network) seems very concerning to me. I know that an ISA will in theory filter via proxying any threats, but what if it’s some sort of new zero day buffer overflow attack?

    I assume that at some level of the data the HTTP/HTTPS requests are forwarded verbatim through the ISA proxying to the CAS. If some new attack on the CAS were found with some sort of constructed known HTTP(S) payload, not yet known to ISA developers, it could be forwarded to the CAS via the ISA and a compromise happen.

    Yes, there are a number of mitigating difficulties for an attacker, but this scenario seems relatively plausible and given what a high value target CAS servers might be to a hacker, it might be well worth one’s effort.

    With the CAS on the inside with no further firewalling, clearly this would place the rest of your networks wide open for attack.

    I’m not sure why the CAS can’t (shouldn’t) be firewalled and/or why there aren’t instructions to do so. We use a enterprise class firewall that has 5gb of throughput, so in theory the high bandwidth requirements could be met. Anything can and should be firewall-able. This is what host intrusion prevention is often about. It should just be a case of defining the required ports and making sure sufficient bandwidth/performance exists through the firewall.

    I suppose one option would be to place the entire Exchange infrastructure in a DMZ, including Mailbox Server, Hub Transport Server, and Client Access Server and just pinhole the Exchange services into that, leaving access between the Exchange components wide open. Is this what some do?

    Really, putting the CAS on the inside gives me the willies. It doesn’t seem "best practice" at all to me.

  9. Kristian Andaker says:

    Hi Scathew,

    Great points! And a topic we spent many hours discussing as we designed Ex2007.

    Whenever you deploy access to an intranet server on the Internet, you will need to select which level of security you apply.

    The #1 most effective way to mitigate the risk you mention is to do "pre-authentication" on the ISA server or other reverse proxy you have in your Perimeter network (aka. "DMZ"). By authenticating users there before their requests reach your intranet, you reduce your CAS surface area considerably.

    ISA 2006 is an example of a reverse proxy/firewall product which includes support for pre-authentication for various Ex2007 services.

    Putting CAS servers in the Perimeter network seems like a good idea since they interpret and execute HTTP requests which were formulated by clients out on the Internet (after, as you say, those requests have been inspected by ISA and other reverse proxies + firewalls).

    Putting CAS servers in the Perimeter network turns out to do little good though, because the CAS servers are so well connected to everything on the intranet that you’d have to open your internal Perimeter network firewall up so it would look like Swiss Cheese.

    Eg. CAS servers must be members of the same AD forest/site as the MBX servers they access.

    Eg. CAS servers have lots of access rights to your AD infrastructure.

    Eg. CAS servers have lots of access rights to other Exchange servers such as your MBX servers.

    Eg. CAS servers use quite a few different ports, and a few protocols, to talk to the different intranet servers they interact with.

    For these reasons, there is little value in putting a CAS in the perimeter network. There are two significant drawbacks:

    1. You’ll be weakening your internal perimeter network firewall, since you would need to open up a bunch of ports.

    2. From past experience we know that many Exchange customers who try to put E2003 FE servers (which were supported running in the perimeter network) in the perimeter network run into all kinds of configuration and functionality problems related to firewall configuraton. This translates to lots of deployment complexity.

    For Exchange roles that we feel need to be in the perimeter network (this only applies to Ex2007 Edge servers), because they are the first autheticating server and the first protocol-filter server for Internet traffic, we spent lots of time ensuring you can deploy them in the perimeter without the two issues listed above. Eg. an Edge server does not need to be a member of the AD forest/site of the other Exchange servers it communicates with.

    Hope that makes sense,


  10. James Lawyer says:

    Is the problem DS2MB resolved yet? This keeps disabling Intergrate Authentication in my environment.

Comments are closed.

Skip to main content