Get-ExchangeHelp

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 11
  • 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.  Of course it is recommended to utilize the front end & back end topology for deployment. 

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:

 

 Get-WebApplication

 

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 MSExchangeServices

 

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.

~Craig 

 

 

Comments
  • 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!

  • 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 http://enterpriseit.co/microsoft-exchange/2013/configure-virtual-directories-eac/

  • 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!

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