This is a tale of when a “quick” review of CAS namespaces quickly went off at a tangent. When working with the messaging administrator, let’s call him “Mike” to protect the innocent, he showed me the below for his Exchange 2013 server. He was quite happy with the config, but that bubble was about to be popped. Note that the ShowMailboxVirtualDirectories parameter has been added to allow us to see the URLs set on both web sites.
To illustrate the difference, the red box below highlights the Exchange back end website, and the yellow box highlights the default website. The back end site is used by the mailbox role, and CAS uses the default website.
Get-WebServicesVirtualDirectory -Server Exch-2013 -ShowMailboxVirtualDirectories | FL Identity, *URL*
Mike "the innocent” administrator was surprised to learn that changes had been made. To illustrate the differences, the below image is from one of my reference Exchange 2013 systems. Note that:
-
The format of the back end InternalNLBBypassURL is different than the above
-
There is no InternalNLBBypassURL on the default website
For easy comparison the InternalNLBBypassURLs are laid out below:
https://exch-2013.wingtiptoys.ca:444/ews/exchange.asmx
https://mail.wingtiptoys.ca/EWS/Exchange.asmx
For reasons unknown to “Mike” the back end InternalNLBBypassURL was changed. The correct format is for it to be the server FQDN, targeting port 444 TCP. How it was changed was also unknown.
Correcting Default WebSite InternalNLBBypassURL
Let’s start with the easy task. The InternalNLBBypassURL should be empty on the Exchange 2013/2016 CAS default website. The value will be set to $Null.
Get-WebServicesVirtualDirectory -Server Exch-2013 | Set-WebServicesVirtualDirectory -InternalNLBBypassUrl $Null
Good. Now to move onto the next task, correcting InternalNLBBypassURL for the back end website.
Correcting Back End Website InternalNLBBypassURL
In order to correct the back end issue, the exact identity of the website and virtual directory is required. We can get that with:
Get-WebServicesVirtualDirectory -Server Exch-2013 -ShowMailboxVirtualDirectories | FL Identity
The identities are shown for reference below, the backend is highlighted as that will be used.
Identity : EXCH-2013EWS (Exchange Back End)
Identity : EXCH-2013EWS (Default Web Site)
Since I normally hate having to type all of that, I typically use –Server to specify the server when working with virtual directories, but that falls down when the task requires more precision. That is the case here, and we need to target a specific virtual directory.
So far so easy. Let’s just set that badboy, and we are done.
Set-WebServicesVirtualDirectory -Identity "EXCH-2013EWS (Exchange Back End)" –InternalNLBBypassUrl "https://Exch-2013.wingtiptoys.ca:444/EWS/Exchange.asmx"
The operation on virtual directory "EXCH-2013EWS (Exchange Back End)" failed because it's out of the current user's
write scope. Unable to perform the save operation. 'EXCH-2013EWS (Exchange Back End)' is not within a valid server
write scope.
+ CategoryInfo : InvalidOperation: (EXCH-2013EWS (Exchange Back End):ADObjectId) [Set-WebServicesVirtual
Directory], InvalidOperationException
+ FullyQualifiedErrorId : [Server=EXCH-2013,RequestId=2b622ef8-3e39-4854-8419-8aa50f916e29,TimeStamp=6/15/2016 1:07:23 AM] [FailureCategory=Cmdlet-InvalidOperationException] 5CBBD391,Microsoft.Exchange.Management.SystemConfigurationTasks.SetWebServicesVirtualDirectory
+ PSComputerName : exch-2013.wingtiptoys.ca
The operation on virtual directory "Exchange Back End" failed because it's out of the current user's write scope. Manipulation of the back end virtual directories is not a standard Exchange 2013/2016 management task. We normally update and manage the default web site’s virtual directories which is for CAS.
KB 2778897 -- Cannot access Outlook on the Web or the EAC after you re-create the "owa" or "ECP" virtual directory on an Exchange Server Mailbox server describes a similar issue where the workaround is to directly load the Exchange PSSnapIn.
As discussed in Directly Loading Exchange 2010 or 2013 SnapIn Is Not Supported directly loading the Exchange PowerShell SnapIn is only to be done in specific circumstances. This blog post does not claim the process below is supported. Contact Microsoft support for guidance before proceeding.
On the Exchange server, the Exchange PowerShell module is directly loaded into Windows PowerShell.
In Windows PowerShell the same command as above was executed:
Set-WebServicesVirtualDirectory -Identity "EXCH-2013EWS (Exchange Back End)" –InternalNLBBypassUrl "https://Exch-2013.wingtiptoys.ca:444/EWS/Exchange.asmx"
Windows PowerShell is then closed, and normal management is resumed in the Exchange Management Shell.
The server now has the the configuration updated on both the default and back end websites.
Note: updated to correct the NLBBypassURL to match the correct server name.
Update 26-7-2016: There is a known issue corrected in Exchange 2016 CU2 which will also cause a server which has been recovered to have an incorrect EWS URL. This is covered in KB 3128167 "HTTP status 404” error when you access free-busy information for mailboxes on a recently recovered Exchange Server 2013 Mailbox server. Thanks to Paul Cunningham for the note!
Cheers,
Rhoderick
