How Exchange Server ActiveSync (EAS) scales for us
Published Dec 13 2004 12:16 PM 1,334 Views

This afternoon I received the Exchange Server ActiveSync (EAS) usage statistics for the month of November.  Our friends at MS IT told me that our internal user base is growing:  we are at about 7000 unique users at Redmond!!! These users were served about 900,000 connections. Woah!

Some may think that it must take lots of resources to support synchronization for 7k devices, this is indeed NOT the case (at least with EAS)…you should read the MS IT scalability paper, which describes what environment MS IT is running and how they are using two servers to support not only the 7k devices, but also OWA, OMA and RPC/HTTP for the entire Redmond campus!!! (http://www.microsoft.com/windowsmobile/business/whitepapers/scalability.mspx)  

As I was looking at the stats I remembered the discussions that I recently had with many Exchange administrators at IT Forum few weeks ago about scalability and reliability of EAS in Exchange Server 2003.   As you all probably know Exchange Server ActiveSync is a “standard” web server application, it runs along with Outlook Web Access.  The critical point is that EAS is a stateless server: each request from the client is processed independently.  There are several benefits that are derived from this approach, to name few:

      - Users are not bound to any server, when a server is unavailable the client request can be processed by any other available resource

      - There is no requirement for any affinity if you deploy a network load balance solution

      - As your deployment grows, you simply scale “out” and add an additional Exchange Front-end server and get even more devices to connect

There is one trick that you can use to further improve the reliability of the EAS solution.  By default, OWA and EAS share the same default application pool.  You can create a new application pool and bind the EAS website (or virtual directory) to the newly created application pool.

- Max Ciccotosto

4 Comments
Not applicable
Max, good info!
Is there a good whitepaper or architecture article on how EAS requests data or works with the back end server ? It looks to be http requests rather than a mapi client, is that correct ?
Not applicable
Hello Folks. Some more information please, you installation is big, mine is really small.

How do you measure that. Analysing the IIS-Logfiles with a custom tool, vbscript to extract the "POST /Microsoft-Server-ActiveSync " URLS ?

Do you have some more statistical things like:
- how often/regulary are the users replicating
- ho many kilobytes are transmitted per user per replication
- how many are more "light" users and how many are more heavy users.
- where do the come from (you can check the IP-address of the remote site

and many more.

I personally use a MDA3 (german http://www.msxfaq.de/clients/mda3.htm) and it takes about 30-70kbyte per Replication for my normal usage. I replicate manually 3 times a day. unfortunaly notification is not working here in germany (sending a SMS notification is about 19 eurocent here, so its cheaper to replicate every 30 minutes or get a blackberry)

I personally (small environment) use a simple "FIND" againsts the IISLogs to extract the MobileSyncURLs and analyse the Logs with tools like analog, webalizer etc to get more informations about it.

maybe you have some statistical data for us ?
But its still great to know, that EAS scales so nice. Thanks

To Answer a question: YES EAR-request are HTTP_request and a i know they are handled by the MASSYNC.DLL, which uses OWA to access the information in the usermailbox. (It looks like a HTTP-reverseProxy with rewriting for me :-)
So don't enable Formbased Auth and other stuff without reading Q817379

Frank
Not applicable
Hello Frank, we do have some tools that we use to track usage. It's a topic for a different blog :)
Not applicable
I'll still monitor that blog, so i'll not miss any additional informations about your tools to track the usage. Frank
Version history
Last update:
‎Jul 01 2019 03:02 PM
Updated by: