Setting Backend Exchange 2013 / 2016 Virtual Directory

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.

Example of Incorrect InternalNLBBypassURL Configuration

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*

Example of Incorrect InternalNLBBypassURL Configuration - Highlighted to Show Different Web Sites

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

Example Of InternalNLBBypassURL Configuration - Highlighted to Show Different Web Sites

For easy comparison the InternalNLBBypassURLs are laid out below:


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

Changing NLBBypassURL On Default Website


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

Retrieving Identity For Virtual Directories On Different Websites

The identities are shown for reference below, the backend is highlighted as that will be used.

Identity : EXCH-2013\EWS (Exchange Back End)

Identity : EXCH-2013\EWS (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-2013\EWS (Exchange Back End)" –InternalNLBBypassUrl “

Attempting To Set Exchange Back End WebSite - Out Of Write Scope

The operation on virtual directory "EXCH-2013\EWS (Exchange Back End)" failed because it's out of the current user's
write scope. Unable to perform the save operation. 'EXCH-2013\EWS (Exchange Back End)' is not within a valid server
write scope.
    + CategoryInfo          : InvalidOperation: (EXCH-2013\EWS (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        :


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.

Caution - Directly Loading Exchange PowerShell SnapIn Only In Specific Circumstances


In Windows PowerShell the same command as above was executed:

Set-WebServicesVirtualDirectory -Identity "EXCH-2013\EWS (Exchange Back End)" –InternalNLBBypassUrl “


Set Exchange Back End WebSite InternalNLBBypassURL

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.

Updated Configuration For Both 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!  



Comments (20)
  1. Thanks
    very interesting

  2. RobK_ says:

    Hi Rod

    If I have Exchange 2013 CAS and Mailbox running on separate servers will i run into this problem? Or this only happens when all roles reside on one server?

    thank you

    1. Hi Rob,

      This will not happen in normal situations even if you multi role. This customer did unusual things……


      1. RobK_ says:

        cool thank you

      2. RobK_ says:

        cool thank you
        BTW do you know if Microsoft is ever going to fix the -verbose switch on exchange 2010/13/16 running on newer OS like Windows 2012R2? right now running command like get-mailbox -verbose does not produce yellow output. If running on Windows 2008R2 you do see the yellow output. I;m hoping maybe with release of Windows 2016 they will finally squash this bug. very annoying.

        thank you

        1. RobK_ says:

          I guess this question will never be answered. Just wondering if this is an OS issue or Exchange issue.


          back to the original topic. Can you make the change directly in ADSIEDIT under CN=EWS (Exchange Back End), CN=HTTP,CN=Protocols,CN=ServerName,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT)….. on msExchInternalNLBBypassHostName attribute?

          thank you

        2. Oh, I’ll take a look. But remember that onsite customer work is my role at Microsoft. Blogging is something that I choose to do in my free time.

          Do not use ADSIEdit unless specifically instructed. In this case we can get to the values using Exchange tools.


          1. RobK_ says:

            Thank you for your reply

  3. scratchbuild1 says:

    You, sir, are a king. Thank you for sharing this. After two weeks troubleshooting with Microsoft, I will now be able to go back to them having already fixed it.

    1. scratchbuild1 says:

      Your blog should be required reading for the support engineers!

      1. 🙂

        May I ask what was the issue you were facing? I do a very similar role to the SE, and I do know that some of them do read my rants here.


  4. JimG says:

    Seeing -ShowMailboxVirtualDirectories was like a gift from heaven. I’ve been working on a DAG deployment (2 servers, CAS and Mailbox roles on each, plus a FWS) and were having all sorts of issues. I unfortunately followed the advice of someone regarding the auth settings on both the Default Website and the Exchange Back End (for both ECP and OWA), which hosed the whole thing. I could not tell what the Exchange Back End auth settings were until I came across your blog. I expect to be able to change them to the correct settings now that I can compare them to a working Exchange 2013 server. I’m literally breathing a sigh of relief after 24 hours of chaos. Thank you my friend,

  5. Ann says:

    Hi Rhoderick,

    is this valid also for all other VDirs (activesync, owa etc)? Do we have empty internalURL, empty externalURL, and InternalNLBBypassUrl populated with FQDN on the backend vdirs?

    1. Hi Ann,

      I’m not in front of a server right now, but that is what should be the case.

      Please note that only the EWS VDir has the InternalNLBBypassURL. That was due to Exchange 2007/2010 CAS-CAS proxy requirements.

      Are you seeing something else?


  6. AndyShannon says:

    I followed your steps on a brand new Exchange 2016 CU4 server i just built, but when i get to the windows powershell steps and try to execute that command i get a response back saying:
    An IIS directory entry couldn’t be created. the error message is Access is denied.

    Any ideas?

    1. Hi Andy,

      These steps should not be required in normal situations. It is only for when “unnatural” things have been done.

      What drove you down this path please?


      1. AndyShannon says:

        Nothing really so far, just did a fresh install of Exchange 2016 cu4 and following this guide:

        Exchange 2016 ECP was working fine for first 3 days after install then Just did the step where i updated the service connection point and now trying to move the certificate over and cannot log into ECP anymore, just get a “page not found” message.

      2. AndyShannon says:

        Does that help any?

  7. Paul says:

    I had this exact issue after a fresh install to a new Server 2016 server. I detect a tone in your article that seems to imply someone made this change stupidly. Well that’s certainly not the case in my situation. You should probably tone down the rhetoric. Especially in the comments here.

    There are bugs in this software. Another fresh install of Exchange 2016 on Server 2016 left an old insecure cypher working in IIS. So all our users accessing OWA via Chrome or Firefox wouldn’t load the site because of the bad cypher. IE of course would still happily load it with not even a warning. Had to edit the registry of all things to fix this.

    I’ve spent hours messing with this mess, and now am rather offended by your implication that we cause these problems ourselves.

    Oh, I just saw your update at the bottom. Well funny. We still have the issue in the most current cumulative update that was installed along with the Exchange install. I think we are on CU 5 now.

    Great work, Microsoft.

    1. Hello Paul,

      What is the issue that you experienced – the certificate not being bound to the back end web site?


Comments are closed.

Skip to main content