locked
Disable ActiveSync Proxying on specific servers RRS feed

  • Question

  • We are in the process of migrating from Exchange 2007 to Exchange 2010 in my environment. We use a 3rd party product to manage Activesync and it is configured to point to a 2007 CAS in Site1. All CAS servers in all sites, both 2007 and 2010, have their ExternalURL properties set to $null. For the InternalURL value, the 2007 CAS are configured to point to themselves, while the 2010 CAS are configured to point to the hardware load balanced client access array in their respective sites.

    The problem is that the 2007 CAS in Site1 is occasionally attempting to proxy to the 2010 CAA in the other sites. This causes the ActiveSync devices to get errors since they are trying to proxy from 2007 to 2010, which is not supported.

    Unfortunately, our 2010 environment is still in the beta phase, which is why the EAS product is still pointing to a 2007 CAS. Since none of our 2010 beta mailboxes have EAS devices, I would like to prevent the 2007 CAS from proxying to the 2010 CAS' in other sites. I thought it would be enough to simply set the InternalURL value on each 2010 CAS ActiveSync virtual directory to $null, but that doesn't seem to be working. Even after performing an iisreset /noforce on the 2010 CAS and also restarting all Exchange services on the 2007 CAS, it is trying to proxy to the Exchange 2010 CAA name in the other sites.

    I understand that the above configuration is not supported, but I would need to set it up this way until the 2010 CAS are production-ready.

    I thought that the only way Exchange "knows" how to proxy EAS to another site is via the InternalURL value. Is this not the case? Do I need to make a change somewhere else? If not, what do I need to do to make the servers pick up this change? is iisreset /noforce enough? Do I need to restart services? On which servers? the 2010 CAS? the 2007 CAS? Both?

    Thanks,

    Dan

    Wednesday, February 15, 2012 3:23 PM

Answers

  • I resolved the issue. It looks like it was due to an Exchange 2007 CAS that was meant to be decommissioned but never was. Its InternalURL was pointed to the Exchange 2010 CAA URL in its site with the thought that the servers in the other site would enumerate this as a Exchange 2010 object. However, that is not how the enumeration process works. A CAS in one site enumerates all CAS in a destination site, then caches them based on Exchange version. Then, when proxying to that site is required, it pulls one CAS of the appropriate version from the cache and then sends to that server's InternalURL, whatever the value is. Once I changed the InternalURL for the offending 2007 CAS to point to another 2007 CAS in the same site, then recycled the the MSExchangeSyncAppPool app pool on the source site's CAS servers, issue was resolved.

    I would like to thank everyone who replied to this thread and helped with this issue.

    Dan

    Tuesday, March 20, 2012 1:23 PM

All replies

  • is there are reason why you are not using the legacy.domain.com URL. The goal is eventually to have teh third party point at 2010 right?

    http://blogs.technet.com/b/exchange/archive/2009/12/08/3408985.aspx

    Wednesday, February 15, 2012 6:47 PM
  • The Exchange 2010 servers are not yet production-ready, therefore we do not want them to be the externally-accessible EAS endpoints. We only want a single external EAS URL, which is why we cannot use the "legacy" URL.

    Basically, my question is how do stop particular servers in a site from accepting proxied EAS connections?

    I have tried setting the "InternalURL" on these servers' EAS virtual directories to $null, but connections are still being proxied

    I forgot to mention that all the Exchange 2007 servers are running SP3 RU2, and all 2010 servers are running SP1 RU4

    Wednesday, February 15, 2012 9:35 PM
  • "The problem is that the 2007 CAS in Site1 is occasionally attempting to proxy to the 2010 CAA in the other sites. This causes the ActiveSync devices to get errors since they are trying to proxy from 2007 to 2010, which is not supported"

    Why is that?

    What CAS is external facing and in which AD site?

    The users who are proxied have their mailbox on what mbx server and in which AD site?


    Sukh

    Wednesday, February 15, 2012 10:24 PM
  • There is technically no "Externally-Facing" CAS (I.E. all CAS in the org have their ExternalURL property set to $null) because all EAS connections are proxied through a 3rd party product that accepts the external connections and proxies them to a singe Exchange 2007 CAS "CAS1" in Site1.

    All users with EAS devices, exept a single test user, have their mailboxes on Exchange 2007, and most of the users who are being proxied are in Site2; users in Site1 have no problems.

    For the one test mailbox on Ex2010, CAS1's App log does generate an error that the mailbox is on a later version of Exchange, which is expected.

    Furthermore, the IIS logs on CAS1 show the failed proxy attempts to the Exchange 2010 servers in Site2, even over 24 hours after the InternalURL value for each was set to $null, the 2010 CAS' were restarted, and, on CAS1, all Exchange services were restarted.

    My main question is that if none of the EAS virtual directories have either InternalURL or ExternalURL populated, why is CAS1 attempting to proxy to them? is it getting these URLs from somewhere else?

    Thursday, February 16, 2012 1:47 PM
  • I have tried setting the "InternalURL" on these servers' EAS virtual directories to $null, but connections are still being proxied


    How long after doing this are you seeing these connections still being attempted?

    Microsoft Premier Field Engineer, Exchange
    MCSA 2000/2003
    MCTS: Win Server 2008 AD, Configuration MCTS: Win Server 2008 Network Infrastructure, Configuration
    MCITP: Enterprise Messaging Administrator 2010
    Former Microsoft MVP, Exchange Server

    NOTICE: My posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thursday, February 16, 2012 1:48 PM
  • What exch 2007 server exist in site 2?

    So all users who are proxied have their mbx at sitr 2 right?


    Sukh

    Thursday, February 16, 2012 2:16 PM
  • It has been over 24 hours and CAS1's IIS logs are still showing attempted connections to the 2010 CAS in Site2, which are failing with error 403.
    Thursday, February 16, 2012 2:25 PM
  • What exch 2007 server exist in site 2?

    So all users who are proxied have their mbx at sitr 2 right?


    Sukh

    There are 2007 and 2010 servers of cas, ht, and mbx in all sites.

    Yes, everyone in a site other than Site1 are getting proxied

    Thursday, February 16, 2012 6:29 PM
  •  

    Hi,

    Maybe you can disable activesync on the beta Exchange Server.

    You can refer to the following link.

    Selectively disabling ActiveSync on certain Exchange 2003/2007 servers:<//span>

    http://social.technet.microsoft.com/Forums/en/exchangesvrmobility/thread/c15c9e94-1d1f-4966-912e-d96a8a4a5d79

    Wendy

    Friday, February 17, 2012 11:05 AM
  •  

    Hi,

    Maybe you can disable activesync on the beta Exchange Server.

    You can refer to the following link.

    Selectively disabling ActiveSync on certain Exchange 2003/2007 servers:<//span>

    http://social.technet.microsoft.com/Forums/en/exchangesvrmobility/thread/c15c9e94-1d1f-4966-912e-d96a8a4a5d79

    Wendy

    I have tried disabling ActiveSync on the Exchange 2010 CAS servers by stopping the "MSExchangeSyncAppPool" Application pool, but the problem persists. The 2007 CAS is still attempting to proxy to the 2010 CAS', but now, instead of the "403" errors, it is getting "503" errors.

    I am still perplexed as to where it is getting the internal URL from the Exchange 2010 servers since it is now null. Is it possible that the 2007 CAS has this information cached somewhere?

    I am now thinking of changing one of the internal URLs of the 2010 CAS servers to see if it tries to proxy to it and test whether or not the 2007 CAS is properly refreshing the names.

    Anyone have another idea?

    Friday, February 17, 2012 6:26 PM
  •  

    Hi ,

    It looks like still go to Exchange 2010 CAS ActiveSync Virtual directory.

    Do you have Remote Wipe on devices and test again ?

    You can try to Remote Wipe on the basis of the article, and reset mac to download the configuration.

    Managing your Active Sync Device from Outlook Web Access in Exchange 2007 SP1

    http://blogs.technet.com/b/exchange/archive/2007/05/30/3402915.aspx

    Thank you.


    Wendy

    • Marked as answer by wendy_liu Friday, February 24, 2012 9:29 AM
    • Unmarked as answer by Daniel DeStefano Tuesday, March 20, 2012 1:14 PM
    Monday, February 20, 2012 9:34 AM
  • I resolved the issue. It looks like it was due to an Exchange 2007 CAS that was meant to be decommissioned but never was. Its InternalURL was pointed to the Exchange 2010 CAA URL in its site with the thought that the servers in the other site would enumerate this as a Exchange 2010 object. However, that is not how the enumeration process works. A CAS in one site enumerates all CAS in a destination site, then caches them based on Exchange version. Then, when proxying to that site is required, it pulls one CAS of the appropriate version from the cache and then sends to that server's InternalURL, whatever the value is. Once I changed the InternalURL for the offending 2007 CAS to point to another 2007 CAS in the same site, then recycled the the MSExchangeSyncAppPool app pool on the source site's CAS servers, issue was resolved.

    I would like to thank everyone who replied to this thread and helped with this issue.

    Dan

    Tuesday, March 20, 2012 1:23 PM