Hi

I have an exchange 2013 server with Client Access and Mailbox server installed. The server has an second ip address which I have bound an additional IIS site to. The additional IIS site is named ExchangeExternalFBA.

The default web site is configured for basic and windows authentication with:
Set-EcpVirtualDirectory -identity "ecp (default web site)" -FormsAuthentication:$false
Set-owavirtualdirectory -identity "owa (Default Web Site)" -FormsAuthentication:$false -WindowsAuthentication:$true -BasicAuthentication:$true

Then a new ECP and OWA are configured with:
New-ecpVirtualDirectory -WebSiteName "ExchangeExternalFBA"
New-OwaVirtualDirectory -WebSiteName "ExchangeExternalFBA"
Set-owavirtualdirectory -identity "owa (ExchangeExternalFBA)" -LogonFormat FullDomain -FormsAuthentication:$true -WindowsAuthentication:$false -BasicAuthentication:$true
Set-EcpVirtualDirectory -identity "ecp (ExchangeExternalFBA)" -FormsAuthentication:$true

Then I perform an iisreset.

My problem is that then when I try to access the ECP or OWA on the default website, it loads forms authentication! The ECP or OWA on the ExchangeExternalFBA web site works correctly and also loads forms authentication.

If I run...
get-owavirtualdirectory "owa (ExchangeExternalFBA)"

then it returns:

InternalAuthenticationMethods                       : {Basic, Ntlm,
                                                      WindowsIntegrated}
BasicAuthentication                                 : True
WindowsAuthentication                               : True
DigestAuthentication                                : False
FormsAuthentication                                 : False
LiveIdAuthentication                                : False
AdfsAuthentication                                  : False
OAuthAuthentication                                 : False

If I then run

Set-EcpVirtualDirectory -identity "ecp (default web site)" -FormsAuthentication:$false
Set-owavirtualdirectory -identity "owa (Default Web Site)" -FormsAuthentication:$false -WindowsAuthentication:$true -BasicAuthentication:$true

and perform another iisreset then when I try to access the ECP or OWA on the default website it loads correctly. But then the forms based authentication on the ExchangeExternalFBA website can no longer log in, it does not accept the user name and password. If I then disable and enable FBA on the ExchangeExternalFBA website then it works but forms based authentication takes over the default web site again!

Whether I perform the above from the gui or from powershell it does not make a difference, the same behaviour is observed. Changing the logontype on the FBA does not make a difference.

This has been tested on exchange 2013 cu1 and cu2.

Similar(if not identical until they get sidetracked) issue reported in http://social.technet.microsoft.com/Forums/exchange/en-US/9fcd360f-6658-4940-add7-2f13265cf86b/multiple-owa-sites-on-a-single-server-2012-with-exchange-2013-mailbox-cas.

This worked fine in outlook 2007 and 2010, why now do my virtual directories break each other?

I can reproduce the issue on a test exchange 2013 I built in dev.

Is this a bug or are you no longer meant to host different forms of authentication on a single cas?

I'm mostly interested to see if this works for other people and why it no longer seems to work in 2013, so please no questions; 'why do you want 2 different forms of authentication'. 

Much appreciated, Thanks!

You need to add -Role FrontEnd to the New-*VirtualDirectory commands.

Based off of your feedback I have run the following:


Remove-OwaVirtualDirectory "owa (ExchangeExternalFBA)"
Remove-EcpVirtualDirectory "ecp (ExchangeExternalFBA)"
iisreset
Set-EcpVirtualDirectory -identity "ecp (default web site)" -FormsAuthentication:$false
Set-owavirtualdirectory -identity "owa (Default Web Site)" -FormsAuthentication:$false -WindowsAuthentication:$true -BasicAuthentication:$true
New-ecpVirtualDirectory -WebSiteName "ExchangeExternalFBA" -Role ClientAccess
New-OwaVirtualDirectory -WebSiteName "ExchangeExternalFBA" -Role ClientAccess
Set-owavirtualdirectory -identity "owa (ExchangeExternalFBA)" -LogonFormat FullDomain -FormsAuthentication:$true -WindowsAuthentication:$false -BasicAuthentication:$true
Set-EcpVirtualDirectory -identity "ecp (ExchangeExternalFBA)" -FormsAuthentication:$true
iisreset


After this there has been no change in behaviour. After the iisreset, forms have again hijacked the default web site and re-setting the authentication on the default web site removes the forms but breaks the ability to sign in to the forms based page on the ExchangeExternalFBA web site again.


Note. '-Role Frontend' did not work. It showed the error:

Cannot process argument transformation on parameter 'Role'. Cannot convertvalue "frontend" to type
"Microsoft.Exchange.Management.SystemConfigurationTasks.VirtualDirectoryRole".
Error: "Unable to match the identifier name frontend to a valid enumerator name.  Specify one of the following enumerator names and try again:
ClientAccess, Mailbox"
    + CategoryInfo          : InvalidData: (:) [New-OwaVirtualDirectory], ParameterBindin...mationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,New-OwaVirtualDirectory


Running get-help New-OwaVirtualDirectory -detailed shows the correct usage would be '-Role ClientAccess'?

    -Role <ClientAccess | Mailbox>
        The Role parameter specifies the configuration that should be used
        when the virtual directory is created. The following are the values
        that can be used with this parameter:
        * FrontEnd Configures the virtual directory for use on a Client Access
          server.
        * BackEnd Configures the virtual directory for use on a Mailbox server.

I was basing on the documentation:

http://technet.microsoft.com/en-us/library/bb123752(v=exchg.150).aspx

which says it's "FrontEnd'.

I received notification that this was marked as answered which I have reversed.

I may not have been entirely clear but:

the suggested command did not work because it was the wrong syntax despite what the documentation said

the command based on the adjusted syntax did not make a difference. Changing auth on one OWA still interfered with auth on the other.

Thanks

I must share with you that I tried doing what you're doing and it broke OWA completely and I ended up having to reinstall, so I share your pain.  I honestly don't know if it's possible to do this in Exchange 2013 as it was in 2010.  I'll work on it in my lab when I have a chance and get back to you if I can come up with a method.  In the meantime, if you can come up with a solution, please post here or, better, write a blog post first!

For now I've given up on hosting multiple OWA sites with different authentication. I may revisit it later as time permits but at the moment it's a lesser priority.

Thank you for your feedback.

The problem is simple - after you create the second ECP and OWA on the Second new Website you need to do this:

1. Go to your \Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy

make a copy of owa and ecp to owa2 & ecp2.

2. Right click on each respective folder and change the path on the two new OWA and ECP Vdirs in IIS.

3. Re-do your permissions to each OWA and ECP - or least to the one that is currently broke.

When your making those changes you keep stepping on the web.config file.  Since both sites are sharing the same dir. 

thanks,

Randy Sieren - rsieren@iowasolutions.com

• Edited by IowaSolutions Monday, September 30, 2013 2:52 PM
• Proposed as answer by Programatix Tuesday, December 10, 2013 9:43 AM
• Marked as answer by Mr Gr Wednesday, December 11, 2013 3:02 AM

The problem is simple - after you create the second ECP and OWA on the Second new Website you need to do this:

1. Go to your \Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy

make a copy of owa and ecp to owa2 & ecp2.

2. Right click on each respective folder and change the path on the two new OWA and ECP Vdirs in IIS.

3. Re-do your permissions to each OWA and ECP - or least to the one that is currently broke.

When your making those changes you keep stepping on the web.config file.  Since both sites are sharing the same dir. 

thanks,

Randy Sieren - rsieren@iowasolutions.com

• Edited by IowaSolutions Monday, September 30, 2013 2:52 PM
• Proposed as answer by Programatix Tuesday, December 10, 2013 9:43 AM
• Marked as answer by Mr Gr Wednesday, December 11, 2013 3:02 AM

Hi,

I've tested and confirmed that the solution works.

The solution sounds right and makes sense unfortunately for me it's not something I can apply in our production environment. 

Out of curiosity, how well does the fix survive the installation of a service pack or cumulative update?

 web.config

Got it.  Thanks.

 web.config

Got it.  Thanks.

StevenBerkHolz

When you type web.config you are refering the one that should be in wwwroot2?

can you give an example?

tks

Hi Randy, your solution works, so thank you (we are using 2013 CU3).

After the copy of owa and ecp folders, is it mandatory to perform again this copy every CU applied to Exchange Servers, right?

Regards,

D.

David, as you have this working, can you clarify "Right click on each respective folder and change the path on the two new OWA and ECP Vdirs in IIS."  Does this mean to copy these folders (owa and ecp) into the path where you've created the new website (ie - c:\inetpub\mai

Hi Theresa G, after copying the two folders (OWA and ECP, in OWA2 and ECP2), you need to change, the IIS Basic settings of virtual directories /owa and /ecp to point to new paths. In this way the new OWA site virtual directories will use the copied folders (owa2 and ecp2). 

David

Thanks for the clarification David.

I've gone ahead and done that, and it appears to work.  HOWEVER - now, when trying to log into  OWA (default web site) - I get "This page could not be displayed.Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://exservernam.domain.com"? 

OK, I get that on all VDIRS under default website - however, if I go directly to that server and launch owa(https://localhost/owa), I can get into owa fine (just not from other computers (https://servername/owa)?

Nothing has recitified this (have tried deleting, recreating VDirs, etc) - I think I'm at a /m:recoverServer state :)

Now, I've never done this on an Exchange server that still has Exchange installed on it - do I have to uninstall Exchange off the server first, or can I simply run setup/M:recoverServer on it as it sits? Of course, I've moved all the databases off of it, however, it still has replicated copies on it (as it is part of a dag)

Got this working again (the part where I couldn't get to my default website dirs. after this change) - thought I would post in case someone else runs into this.

When I looked at the  bindings for the default web site, there were 2 entries for 443 - one with the typical 127.0.0.1, and one for "all unassigned".  When I looked, the one with "IP Address *" (all unassigned) did not have the certificate listed under SSL Certificate" (In IIS, Defrault Web site,  site bindings, choose the htttps 443 * binding, edit, then go to SSL Certificate).  Assigned the certificate there, and was able to hit all my vdirs under Default Web Site again.