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:
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.