This is just a quick little reference post to answer a question that isn’t well covered. Most Exchange admins are familiar with how to set the Virtual Directories in Exchange after a new server is added or a after initial deployment. What’s less clear to most is what those VDirs actually do as far as Exchange’s capabilities are concerned. I’ll also cover the difference between Internal/External URLs for the VDirs at the end. You may also want to visit this documentation to look at how each VDir’s IIS authentication should be set (in 2016, at least…click the other versions button to select yours).
I really hope everyone understands what this one does, but let’s just include the explanation anyway. OWA VDir is for Outlook Web Access. It’s used to host the website that users will connect to if they are attempting to access their mailbox through a web browser.
This one hosts the website used to access the Exchange Control Panel. ECP allows management of the entire exchange server if you have the correct administrative rights assigned, or advanced configuration of your mailbox if you don’t have admin rights.
This is the endpoint that hosts the XML file used by Outlook and Activesync to determine where the correct Exchange server is for the user’s mailbox.
EWS Virtual Directory
This is one of the more important Virtual Directories to have the URLs set properly on. EWS is Exchange Web Services. EWS provides third party applications and clients with connectivity to the Exchange user’s mailbox in a way that allows those applications to communicate with the mailbox without using MAPI or RPC connections. This makes connections to Exchange more secure and app developer friendly. EWS is responsible for Calendar Sharing outside the Exchange organization, Free/Busy exchange, Out of Office messaging, and a number of other things. If this VDir isn’t set properly, those things may not work.
This VDir allows access to mobile devices that are compatible with Microsoft’s ActiveSync. It is used by any ActiveSync compatible application to access the user’s Mail and Calendar data. ActiveSync is *very* limited in what it can access. Things like shared calendars, delegated mailboxes, and public folders cannot be accessed through ActiveSync.
OAB stands for Offline Address Book. The OAB VDir hosts XML files that contain a downloadable copy of the Exchange Organization’s Global Address List and all other Address Lists that are configured to publish an OAB. This allows Outlook to download the address book for offline/disconnected use.
RPC stands for Remote Procedure Call, and it’s the technique the MAPI protocol uses to exchange mail between servers and clients. The RPC VDir is tied to a feature called Outlook Anywhere (or RPC over HTTPS in some versions). This VDir needs to be set correctly if you want users to be able to access Exchange 2007/2010 from outside the network. In 2013, it is used for computers inside and outside the network. In 2016, it is being replaced with MAPI over HTTPS, which functions a little differently. If this VDir isn’t set correctly, External users will not be able to use Outlook to connect to their mailbox.
This VDir is home to the MAPI over HTTPS protocol used in Outlook 2016 and some versions of 2013. This VDir has to be set in Powershell because it hasn’t been added to the ECP GUI for Exchange. MAPI over HTTPS functions very similarly to RPC, with the exception that the entire protocol utilizes HTTPS for its work instead of just tunneling the RPC requests. It’s a bit more secure to do things this way, and it’s how Exchange will work in the future.
This VDir provides administrators with remote access to the Exchange Management Shell in Powershell. In Exchange 2007/2010, the Exchange Management Shell was access directly from the server. In later service packs for 2010, this was changed to allow Powershell to function over HTTPS, which provides a more secure interface with Exchange.
Internal URLs vs External URLs
Each of the above VDirs can be configured with an Internal and External URL setting. What’s the difference? Well, when applications like Outlook connect to Autodiscover, they are given a URL as a referral in case the application needs to know where to reach each service. The URL that gets used depends on whether the client is joined to the same Active Directory Domain/Forest as Exchange, and whether the client is connected to the same network.
All clients not connected to the same network as Exchange (that is, the IP address of the client as seen by Exchange Server is part of a Subnet that is assigned to an Active Directory Site) will be given External URL settings for everything. Clients on the same network will be given the External URL if they are not a member of the AD Domain/Forest that Exchange belongs to. Clients on the same network that are members of the AD Domain/Forest Exchange is in will receive the Internal URL. In practice, it’s a good idea to make sure the Internal and External URLs are the same for all Virtual Directories in Exchange.
VDirs Where the URL Settings Don’t Matter
There are a few VDirs that have Internal/External URL settings that are not really used for any purpose. OWA and ECP don’t generally get accessed by applications that use Autodiscover, so there’s no requirement that the URL be set. Powershell is usually not used by applications that use Autodiscover, but it can be, so whether it’s set or not depends on your applications.
What URL Do I Use?
You may be wondering which URL you should be using to configure these VDirs. The answer is simple enough. Use a URL that matches the Certificate installed on the Exchange server. If the Certificate has exchange.domain.com listed as an acceptable CN or SAN, use https://exchange.domain.com/whatever. You’ll want to make sure that any certificate used with Exchange includes autodiscover.domain.com at a minimum. Additional names are recommended. If you don’t meet that requirement, you’ll need to use SRV records for autodiscover.