Optimizing your Microsoft Exchange Experience... one Blog post at a time.

Managing Exchange 2013 IIS Virtual Directories & Web Applications

Managing Exchange 2013 IIS Virtual Directories & Web Applications

  • Comments 30
  • Likes

If you've deployed Exchange 2013 in a lab or even in a production environment, you are no doubt getting familiar with the topology changes.  If you are not completely up to speed on the changes, Microsoft has essentially returned to the Front End & Back End topology that was last used back in Exchange 2003.  The front end server is called the Client Access Role, and the back end server is called the Mailbox Role.  The Exchange Roles (i.e. Client Access, Hub Transport, Mailbox) that could be separated in Exchange 2007 & 2010 are still there in 2013, they are just all found on the Mailbox Role servers in Exchange 2013.  The Client Access Role servers are essentially  proxy servers, as all requests are load-balanced and proxied to the corresponding back end server.  Exchange 2013 can also be deployed as an all-in-one server, just like 2007 & 2010.

The purpose of this Blog post is to point out the differences in managing IIS on the Client Access (Front End) & Mailbox (Back End) servers.   


Whether you install your Exchange 2013 server as a Client Access Role or Mailbox Role you will have two Web Sites in IIS:

  • Default Web Site
  • Exchange Back End


The Client Access Role naturally uses the Default Web Site as the home for all the Exchange Virtual Directories (EWS, OAB, RPC, Autodiscover), just as it did in Exchange 2007 & 2010.  The Mailbox Role uses the Exchange Back End site as the home for the corresponding Exchange 2013 Web Applications.

               Client Access Role                                                     Mailbox Role

Although it would appear that these sites are relatively similar, the main difference between the two is not immediately visible until you go to PowerShell to manage the Virtual Directories.  Just as in Exchange 2007 & 2010, you will run the varios commands to manage your Virtual Directories:

  • Get-WebServicesVirtualDirectory
  • Get-OabVirtualDirectory
  • Get-AutodiscoverVirtualDirectory
  • Get-ActiveSyncVirtualDirectory


The first thing you will notice when running one of these commands is that you will get the Virtual Directories for your Front End Client Access servers, but not for the Mailbox servers:


You may be asking why that is... as from looking in IIS they look exactly the same (just in a different Web Site).  If you access the Exchange Admin Center, you will see the same thing:


Despite looking similar in IIS, the main difference between the roles is that all the Virtual Directories are actually located on the front end Client Access servers.  The web applications on the Mailbox Servers can be viewed through the following command:




Why is this important?  I wasn't worried about that answer until a recent customer case.  Essentially we were getting a 404 error when trying to browse EWS.  The Virtual Directories on the front end Client Access servers looked fine, and the logs indicated a problem from the Mailbox servers.  Further investigation on the Mailbox server led me to an interesting discovery... the EWS web application was missing on the Mailbox server!  That certainly explained the 404 error. 

I figured this would be no problem... we'll just create a new EWS Virtual Directory on the Mailbox Server.  Well there are no EWS Virtual Directories on the Mailbox server.  To create a new Virtual Directory requires the Client Access Role, as noted by the following error:


So what now...?     


As it turned out what I needed to do was recreate the EWS web application on the mailbox server using the following command:

New-WebApplication -Site "Exchange Back End" -Name EWS -PhysicalPath "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\exchweb\EWS" -ApplicationPool MSExchangeServicesAppPool


Once this command completed my EWS web application was restored.  I simply had to go into IIS Manger and enable Windows Authentication and the customer's issue was resolved. 

I hope this post will help shed some additional light on how to manage IIS Virtual Directories & Web Applications on Exchange 2013 servers.




  • Nice post

  • Can the web site name "Exchange Back End" change? I need to know the Exchange Back End site for a specified mailbox server. It seems there is no such PowerShell cmdlet. Do you think it is safe to hard code it?


  • Thanks. Question: the virtual directories site of the Mailbox Role have the same authentication settings and others configurations iqual to the site of the Client Access Role? or they are not really important for CAS to Mailbox communications?

  • Excellent post !

  • Amazing information, Helped me identifying the case for one of my cases !

  • Just one comment on this one. New-WebApplication -Site "Exchange Back End" -Name EWS -PhysicalPath "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\exchweb\EWS" -ApplicationPool MSExchangeServices The ApplicationPool name should be “MSExchangeServicesAppPool” you get no warning about a non existens AppPool name when you run the command.

  • Thanks, this was really helpful for understanding the CAS / MBOX changes in 2013. Despite the CAS being a 'proxy' I have found on my deployments that the CAS role still needs to be allocated quite a bit of resources (RAM / PROC) so it must be doing quite a bit of processing/conversion getting the data to and from the mailbox server and the client. After a few deployments I discovered you can still configure the virtual directories using the GUI based 'configure external access' wizard as one could in 2010, I find it a lot easier than using the shell to set the virtual directories on the CAS

  • Hi Craig,

    Can you update please with the remark of @Bo ? Tks. Nice post.

  • Hi there, excellent post. Can the SAME be done with the RPC virtual directory? I seem to be having intermittent issues with this and would like to 'blow away' the back end virtual directory (as it was missing on one mb server but not on the other??) and recreate it again. I also have uninstalled and re-installed the RPC-over-HTTP-Proxy feature, although the default paths of the VD are in %systemroot%. I guess I have two questions. What are the default physical paths for the RPC virtual directories, and can I simply remove and re-add them using the New-WebApplication commands mentioned above?

  • Very useful!

  • Very useful!

  • Hi There, I have a two Node Dag Exchange 2013 MultiRole server. The Usermailbox is on Node One and mounted and in Healthy status. If for some reason the Backend MSExchangeOWAapppool is stopped on Node ONE the user will not be able to access the mailbox, even though the Node Two Mulit role is up and functional. Is the component level failure not detected in Exchange 2013.

  • Thanks for the post. It was quite helpful in understanding virtual directories in Exchange 2013.

  • Craig,

    Thanks a ton for sharing this beautiful piece of writing and explaining with a visual snapshot the differences of IIS in CAS & Mailbox Servers when the roles are hosted on different servers. My situation is like this only. I need a little help.

    I'm asked to setup a new production network with Exchange 2013 and it was an urgent requirement. I started with setting up a lab with 5 VM's running Windows Server 2012 R2.
    1. - Active Directory
    2. & 3. - CAS01 & CAS02 Servers
    4. & 5. - MBX01 & MBX02 Servers

    Setup AD & prepared the Schema for EX2013SP1
    Installed first mailbox server & then tried opening EAC - issue popped up.
    Installed Second mailbox server & then tried opening EAC - issue popped up.
    Installed first CAS server & then tried opening EAC - works fine.
    Installed Second CAS server & then tried opening EAC - works fine.

    I noticed there is a difference between virtual directories on the CAS & Mailbox Servers. I thought I must have done something wrong but when I read your blog I understood that it is by design.

    q1) I'm facing issues only on the mailbox servers to open EAC - so should I modify the virtual directories on the mailbox servers or do something on CAS.

    q2) Since I'm facing issues with EAC (Exchange Administrative Centre) should I only consider modifying the ECP directories on mailbox servers?

    q3) Have you made or is it available somewhere, a table with standard working values that should be present in each virtual directories on both servers - like application pool, physical path, ssl,

    authentication etc.

    q4) What paths should I look for in ADSI.edit for correct settings?

    I need this badly because I've to go live within 2 days and this is my first experience of setting up from scratch.

  • Hey there,

    Any update guys...Today I setup a new lab with only one AD, one CAS & one MBX on three separate VM's. still same issue out of the box...
    This time, Powershell is opening on both CAS & MBX..
    EAC not opening on both servers

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment