Exchange ActiveSync and the /Exchange virtual directory

As many of you already know, Exchange ActiveSync uses HTTP-DAV to access the user’s mailbox. By default these HTTP requests are all sent to the /Exchange virtual directory on the mailbox server. However, in certain deployments like the hosting scenario there can be multiple virtual directories each tied to a particular Domain Name. How does Exchange ActiveSync figure out what mailbox server to go to? What virtual directory to use? What is the mailbox name that is used? Here’s some answers…


If you’ve configured a device to sync to an Exchange server you would have noticed that the only information a user supplies is his/her credentials and the server name - no information as to the user’s mailbox. When a device makes a request to Exchange ActiveSync on the front end server, Exchange ActiveSync first makes an LDAP request to the Active Directory to get back the following attributes on the authenticated user (note that this is not the complete list):







The HomeMDB attribute will be set to the mailbox server name which is how Exchange ActiveSync knows which server to go to for that user. By default Exchange ActiveSync will send its request to the /Exchange virtual directory. So a HTTP-DAV request from Exchange ActiveSync to a mailbox server named mytestserver may look like this:


SEARCH /exchange/mobile1/

Host: mytestserver

Brief: t

Accept-Language: en

Content-Type: text/xml

Content-Length: 2181

Connection: Keep-Alive

Range: rows=0-511


Now, in some cases this default behavior is not desirable – for instance, in the hosting scenario you may have different virtual directories such as:


/Exchange for the domain

/Foo for domain

/Bar for domain


Since all requests will end up going to the /Exchange virtual directory only user’s of the domain can sync. So, is there a way to solve this so the users of all domains can sync? Well, if you have Sp2 you can!! In Sp2 we changed our url format to use the SMTP mailbox addressing scheme so all requests can go to the same virtual directory even if the users are on different domains.  But first let’s take a look at how this currently works in Sp1 and earlier where you could only have it working for a single domain.


Exchange ActiveSync provides a registry key that can be set to make it use a different virtual directory other than the default /Exchange one. The key is under the HKLM and needs an IIS restart to take affect:




If this key is set to the value foo for instance, then all requests to the mailbox server will be sent to the /foo virtual directory as follows:


SEARCH /foo/mobile1/

Host: mytestserver

Brief: t

Accept-Language: en

Content-Type: text/xml

Content-Length: 2181

Connection: Keep-Alive

Range: rows=0-511


We can now have all users on the domain syncing to the Exchange server, however, the users of the other domains won’t be able to.


There is one other piece of information that is important here – the mailbox name. Notice the /mobile1/ part of the url which is the name of the mailbox that we are trying to access. The request above assumes that there exists a mailbox for How did Exchange ActiveSync figure out the mailbox name? The mail attribute on the user object that we get back from the AD contains the primary SMTP address for that user. Exchange ActiveSync simply strips out the left hand side (LHS) of that address and uses that as the mailbox name. This can however break in certain scenarios, what if the user mobile1 did not have a mailbox for


Exchange ActiveSync provides a registry key that can be set to use a proxy address rather than the primary SMTP address. The key is under the HKLM and needs an IIS restart to take affect:




In the example above if we set this key to the value we can then make Exchange ActiveSync use the mailbox name that matches the address for Exchange ActiveSync first checks to see if this key is set. If it is set it walks thru all the proxy email addresses for that user and tries to match up the Right Hand Side (RHS) of the address with the SMTPProxy string set above. If a match is found it then uses the LHS of the matching address, else, it defaults to the LHS of the primary SMTP address. Let’s take the example of the mobile1 user above with the following AD attributes set:


displayName          = Mobile Person

mail                       =

HomeMDB              = mytestserver

ProxyAddresses     =


If the proxy registry key is not set, Exchange ActiveSync would have derived the mailbox name from the primary SMTP address (mail attribute) as follows:




If the key is set to then Exchange ActiveSync will try and match the RHS of the proxy addresses first as follows:



|--------| |-------| ç

    LHS          RHS


In the second case above the RHS will match and so the requests will be sent to the mailbox mperson corresponding to which solves our problem.


SEARCH /foo/mperson/

Host: mytestserver

Brief: t

Accept-Language: en

Content-Type: text/xml

Content-Length: 2181

Connection: Keep-Alive

Range: rows=0-511


In Sp2, we use the SMTP mailbox addressing scheme which was introduced in Sp1 for OWA. This scheme allows us to specify the full emailaddress (not just mailbox name) in the url as follows:


SEARCH /exchange/


What does this buy us and how do we use it? With this new scheme you can host multiple domains in multiple virtual directories with all users being able to use Exchange ActiveSync. The SMTP mailbox addressing scheme basically eliminates the need to point a user to the virtual directory that matches their domain. They can go to any one of the exchange virtual directories regardless of the domain that it’s set to. In the url above, note that the request is actually being sent to the /Exchange virtual directory which is set to the default domain. Since the full SMTP address is supplied the domain used is rather than What’s nice is there’s no change needed to get all this to work – when the front end server is upgraded to Sp2 all requests will immediately start using the new format above so user’s who previously couldn’t sync can sync now!


What’s the catch? Well, there is one requirement for this new feature – the mailbox server that Exchange ActiveSync is accessing must be running at least Sp1.


So, with Sp2, you can host multiple domains and all users can sync!


- Selva Nalliah

Comments (11)
  1. Benjamin Mateos says:

    Really nice !

    A much needed feature.


  2. Anonymous says:

    Great information about the way Exchange ActiveSync works and how ActiveSync searches for the users mailbox

  3. After all the SP2 posts here, all I can say is: "Deliver it – I need it" :-)

  4. Anonymous says:

    Humm, so 324306 XADM: How Exchange 2000 Web Storage System and Exchange 2000 Installable File System…

  5. Flaphead says:

    So does this mean that SMTPProxy is no longer needed or used?

  6. Dan Sheehan says:

    We use a single URL for our 5.5 OWA and 2003 FE. /Exchange/ is owned by 5.5, and /2003/ is owned by 2003 FE. As you noted in SP1, this works great for our OWA users in any domain. But will the SP1 registry key you listed allow us to change the default VDIR for active sync allow us to use /2003/ for all our users? You noted it was an issue in SP1, but it seems like the lookup you all copied from SP1 OWA will allow us to succesfully use a non-default VDIR in SP2 for active sync.

    Great read BTW!

  7. Anonymous says:

     Software / Hardware 

    PalmSource has shifted it’s engineering efforts to focus on…

  8. Dan Sheehan says:

    Was wondering if you could address the VDIR reg hack working with the active synch question I had above.

  9. Selva Nalliah says:

    To answer Dan Sheehan’s question above. Yes, you can still use the VDir registry key. If it is set to /2003 then all ActiveSync users will be redirected to that virtual directory.

  10. m says:

    Just wondering about the SMTPProxy registry key.. Can this have multiple values, i.e.;;

    or will this choke ActiveSync?

  11. Selva Nalliah says:

    "Just wondering about the SMTPProxy registry key..Can this have multiple values?"

    No. We only allow a single proxy string.

Comments are closed.

Skip to main content