Sunday, May 22, 2016

Exchange 2010 (SP3) - Virtual Directory Authentication Settings (some repair options)

In my blog posts on the Citrix NetScaler VPX (used to load balance Exchange), I adjusted some setting of the OWA virtual directory. These settings are crucial for client access to the mailbox via HTTP(S). Knowledge of the default settings and especially repair options are essential for the Exchange administrator.

Some opening remarks

What are virtual directories? They are IIS web shares associated with "real' Windows directories (or folders) containing the files that constitute the various client access services accessible via IIS. For example, if we look at the ecp virtual directory (Content View) and then "Explore" (in the "Actions" pane), we see that this directory provides access to the following Windows folder: 

C:\Program Files\Microsoft\Exchange Server\v14\ClientAccess\ecp

In fact, if we arrange the windows as follows, virtual directories and Windows folders are almost aligned line for line:

Default authentication and SSL settings (Exchange 2010)

These are the settings for the Exchange features that I consider the most useful to understand in my environment (Exchange 2010 multi-role server):

Note: unless otherwise indicated, the authentication settings listed are ENABLED.

As for SSL, all directories listed above require SSL except:
  • OAB
  • PowerShell
  • PowerShell-Proxy.

RpcWithCert requires a client certificate.

Other remarks:
  • Exadmin, Exchange and Exchweb (assuming they are even present) are legacy virtual directories that were used with Exchange 2003.
  • I do not use Public folders or Unified Messaging.
  • Please consult other online documentation if you are interested in virtual directories not presented above.

Reset virtual directories - EMS (PowerShell)

It is possible that virtual directory settings can become misconfigured or corrupt. If all else fails, we can delete and recreate the virtual directory in question.

Before Exchange 2010 SP1, we had to perform this operation in the EMS with the PowerShell cmdlets Remove-OWAVirtualDirectory and New-OWAVirtualDirectory.

If you have more than one Exchange server, make sure you designate only the virtual OWA directory that you want to remove (and recreate). This cmdlet, for example, would remove all the OWA virtual directories in the Exchange organization: 

Get-OwaVirtualDirectory | Remove-OwaVirtualDirectory

Warning: do not execute that command on your production Exchange server(s).

We can see the various OWA virtual directories in the organization with this cmdlet:

[PS] C:\>Get-OwaVirtualDirectory | fl Name,Server

Name   : owa (Default Web Site)
Server : EX13-1

Name   : owa (Default Web Site)
Server : EX13-2

Note: you can use the format-table (ft) option (the default - no need to specify it) or the format-list option (fl). I use the latter because it allows me to keep the output on the left side. It is simply a screen display option and does not affect the number of objects displayed.

We can remove the OWA virtual directory with any one of these combinations of cmdlets (and there are probably even more options):

Get-OwaVirtualDirectory "owa (default web site)" | Remove-OwaVirtualDirectory

Note: I would be cautious with the cmdlet above but apparently when we specify the OWA virtual directory, PowerShell only returns the local virtual directory.

So to be safe, we can indicate the server name:

Get-OwaVirtualDirectory "ex13-1\owa (default web site)" | Remove-OwaVirtualDirectory

Or, since we are indicating the server now, we could simply use this cmdlet (no pipeline needed):

[PS] C:\>Remove-OwaVirtualDirectory "ex13-1\owa (default web site)" -whatif
What if: Outlook Web App virtual directory "ex13-1\owa (default web site)" is being removed.

Note the use of the -whatif parameter which allows us to see if the cmdlet is valid but also tells us what will happen. It can be useful to execute the cmdlet to see what will happen... without the action actually happening.

We recreate the OWA virtual directory with this cmdlet:

New-OwaVirtualDirectory -InternalUrl '' -WebSiteName 'Default Web Site'

Note: we will have to reconfigure the other parameters as well, such as the "-ExternalUrl" but we can do that once the virtual directory has been recreated. This is another example of the wisdom of documenting the Exchange configuration - more on that in the next section (below). Otherwise, we could look at the configuration of the OWA virtual directory on another Exchange server (if we have one... ).

For the changes to take effect, we must restart IIS with the following command: iisreset /noforce 

At this point, we can reconfigure the ActiveSync virtual directory parameters, the Urls for example.

Reset virtual directories - EMC

Since Exchange 2010 SP1, we can reset the virtual directories from the EMC

Regardless, it makes sense to document the existing settings before making changes. We can take screenshots of the various tabs in the virtual directory properties or we can use certain PowerShell cmdlets. Concerning the ActiveSync virtual directory, we can execute this cmdlet for that purpose:

[PS] C:\>Get-ActiveSyncVirtualDirectory "EX13-1\Microsoft-Server-ActiveSync (Default Web Site)" | fl

Note: I will not post all the output since it is quite long.

The internal and external Urls interest me the most and are quite important: if they do not match the names on the certificate we use for the client access services, users will encounter error messages when accessing these sites. So for just the Urls, I can use this cmdlet:

[PS] C:\>Get-ActiveSyncVirtualDirectory "EX13-1\Microsoft-Server-ActiveSync (Default Web Site)" | fl name,*nalurl*

Name        : Microsoft-Server-ActiveSync (Default Web Site)
InternalUrl :
ExternalUrl :

At this point (after taking at least minimal notes on the settings to reconfigure), we can reset the virtual directory. I'll illustrate the process with the following screenshots...

Open the EMC (Exchange Management Console), go to Server Configuration | Client Access and right-click on the server where the virtual directory will be reset. Select "Reset Virtual Directory" in the menu:

We then select the virtual directory to reset:

Note: click "Next" or "Finish" as needed.

In fact, I'll reset the ActiveSync virtual directory:

Result: the Urls are changed to their default values:

[PS] C:\>Get-ActiveSyncVirtualDirectory "EX13-1\Microsoft-Server-ActiveSync (Default Web Site)" | fl name,*nalurl*

Name        : Microsoft-Server-ActiveSync (Default Web Site)
InternalUrl : https://ex13-1.mynet.lan/Microsoft-Server-ActiveSync
ExternalUrl :

There are a number of options to re-enter the previous values of the virtual directory settings. For the most part, the default settings are not changed, except for the Urls. To set the preferred values, we can configure the parameters in the appropriate section of the EMC (Exchange Management Console) or use the EMS (Shell). For OWA, ActiveSync and OAB, it does not matter. However, some virtual directories (such as the EWS directory - Exchange Web Services) can only be configured at the command line, so I'll illustrate the process with that option.

This is one approach (using variables):

[PS] C:\>$AsURL=""

[PS] C:\>Set-ActiveSyncVirtualDirectory "EX13-1\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl $AsURL -ExternalUrl $AsURL

We now have the values that were present before resetting the virtual directory:

[PS] C:\>Get-ActiveSyncVirtualDirectory "EX13-1\Microsoft-Server-ActiveSync (Default Web Site)" | fl name,*nalurl*

Name        : Microsoft-Server-ActiveSync (Default Web Site)
InternalUrl :
ExternalUrl :

Additional remarks

Many properties for Exchange reside in Active Directory. In fact, this is true for the virtual directories. If we open ADSIEdit (configuration partition) and go to the sections in the images below, we can see some now familiar virtual directory settings for OWA:

In his blog, Dave Stork relates an incident where he was not able to recreate the OWA virtual directory with any of the methods described above:

Fixing a broken OWA 2010 Virtual Directory

I'm going to summarize the steps below (from what I understood):

  1. Recreate the virtual directory in IIS (I'm not sure of the exact process here).
  2. Creates a new object on the problem server in ADSIEdit (class msExchOwaVirtualDirectory) - in his situation, this object was missing
  3. Copy attributes from a "good" Exchange server.
  4. It looks like at this point OWA was accessible.
  5. He runs the resets the directory at this point.

I do not know if this procedure is supported by Microsoft but this is might become handy if all else fails. For this reason, I am linking to his post here.

Warning: avoid using ADSIEdit unless you absolutely must do so. It is easy to make mistakes and there is no undo button or recycle bin.


Reset Client Access Virtual Directories

No comments:

Post a Comment