In several recent engagements, there has been some interesting discussions about how to configure the CAS namespaces for the Exchange Web Services virtual directory. Specifically this was around the configuration of the InternalNLBBypassUrl in Exchange 2013 and 2016. Since this was set on Exchange 2007/2010 servers, there seems to be a desire to change it on 2013/2016 servers when troubleshooting free busy lookup failures.
In a similar vein to the Busting The Set-AutodiscoverVirtualDirectory Myth post, let’s take a look at the Exchange 2013 InternalNLBBypassUrl. This post was initially drafted in summer 2015.
As a very quick recap, the InternalNLBBypassUrl was introduced in Exchange 2007 and is used in a CAS – CAS proxy scenario. Exchange 2010 also uses it in the same way. This allows the 2007/2010 CAS server to bypass the load balanced namespace and directly target a server. This is required for a very small number of tasks which must maintain server affinity and not be potentially moved to a different CAS by the load balancer. Hence the name. Internal NLB Bypass URL…. Note only the Exchange Web Services (EWS) virtual directory has this parameter
This is all discussed in the Exchange CAS Bible in excruciating detail. How I remember having to memorise all of that content for MCM….
The concept of CAS 2013 & 2016 is very different from CAS07 and CAS10. This is deliberate. To achieve the design goal of ‘every server is an island’ it was necessary to simplify how Exchange servers communicated.
Lab Configuration
This lab consists of six Exchange 2013 servers and two Windows 2012 R2 DCs, Exchange 2013 CU10 is deployed onto all Exchange servers. This was a pre-canned lab which is why some roles are split out. Please note this is not a recommendation to split roles. Splitting roles goes against the Exchange Preferred Architecture.
Get-ExchangeServer | select Name, AdminDisplayVersion, ServerRole
For reference the Exchange 2013 Build Numbers can be found on TechNet.
Exchange 2013 CAS Role InternalNLBBypassUrl
If we look at server Consea-CAS1, this server is an Exchange 2013 CAS only role.
Get-WebServicesVirtualDirectory -Server Consea-cas1 | Select Name, *URL* | FT –AutoSize
Running the Get-WebServicesVirtualDirectory cmdlet shows that there is no InternalNLBBypassURL configured. It is empty.
This is the default configuration. There is no InternalNLBBypassUrl set on the Exchange 2013 CAS EWS virtual directory. This is how the URL should be configured. For completeness, I would expect that the InternalURL and ExternalURL are set, and are populated with load balanced values. By default the server FQDN is used for the internal URLs, however URLs should be changed to meet your CAS namespace design.
Exchange 2013 Mailbox Role InternalNLBBypassUrl
OK, what about an Exchange 2013 server that only has the Mailbox role installed? Let’s look at server Consea-MB1. This server only has the mailbox role.
Get-WebServicesVirtualDirectory -Server Consea-MB1 | Select Name, *URL* | FT –AutoSize
Oh look, no InternalNLBBypassURL is present! Really?
Well no. Exchange 2013 has the concept of front end and back end virtual directories. Below is a view of the IIS Manager on CONSEA-MB1, which is a mailbox only server. Note that there are two websites, one is called “Default Web Site” and the other “Exchange Back End”. The Default website listens TCP 80 and 443 and is used by CAS. The Exchange Back End site listens on TCP 81 and 444, and is used by the mailbox role. This allows for both sites to exist on a multi role machine, and to permit the proxying behaviour in the every server is an island model. There are other IIS bindings present, but not relevant to this discussion.
At this point you might be curious as to where the EWS virtual directory is in the previous screenshot. We can see that there is an EWS virtual directory under the Exchange Back End site. Why was it not listed in the PowerShell output? We need to add the ShowMailboxVirtualDirectories parameter to the cmdlet to see both sets of virtual directories.
Let’s repeat the cmdlet with the additional parameter present. Again note that is is a mailbox role only server.
Get-WebServicesVirtualDirectory -Server Consea-MB1 -ShowMailboxVirtualDirectories | Select Name, *URL* | FT -AutoSize
Now we can see that the EWS virtual directory in the Back End web site. Port TCP 444 is also used in the URL as that is the configured listening port for the Exchange back End web site.
Exchange 2013 Multi Role InternalNLBBypassUrl
For completeness, if we use the ShowMailboxVirtualDirectories parameter on an Exchange 2013 multirole server which has both CAS and Mailbox role we will see a combination of the above.
Initially the standard Get-WebServicesVirtualDirectory is executed.
Get-WebServicesVirtualDirectory -Server Condal-CAS-MB | Select Name, *URL* | FT –AutoSize
Then we add the ShowMailboxVirtualDirectories parameter:
Get-WebServicesVirtualDirectory -Server Condal-CAS-MB -ShowMailboxVirtualDirectories | Select Name, *URL* | FT –AutoSize
In the above, note that the highlighted red box contains the results of the Exchange 2013 multi role server when the ShowMailboxVirtualDirectories parameter is added.
Popping The Myth
The Exchange 2013 and 2016 CAS are very different from the Exchange 2007/2010 CAS role. As such, the configuration options have changed and troubleshooting methods that were previously valid are now no longer so.
From the above it should be clear that the InternalNLBBypassUrl on Exchange 2013 and Exchange 2016 CAS roles should not be set. Due to the every server is an island design principle, the InternalNLBBypassUrl should be only set on the mailbox role EWS virtual directory. However, it is already set to the server’s FQDN and should not be modified.
In fact, you will not be able to modify the InternalNLBBypassUrl on the Back End website using standard Exchange remote PowerShell. You will have to do unnatural and unsupported things to change those URLs. This is discussed in detail in the Setting Backend Exchange 2013 / 2016 Virtual Directory post.
Cheers,
Rhoderick
