Creating a Secondary OWA Instance

(continued from previous post: AuthAnvil on OWA 2007)

So I set out on the task of creating a secondary OWA instance in IIS for the purpose of securing using AuthAnvil. First, I bound a second IP address to the server under TCP/IP properties. Then I created a new website named "AA-Secured" and set it to only listen on the new IP address. Then I set it to use the same SSL certificate that the original site used (e.g. webmail.domain.com).

So far, so good. I'm no PowerShell guru, but I'm impressed with how versatile it is. I have used it to perform many of the regular Exchange tasks with ease. I'm a command shell junkie at heart, but I never learned how to do "real" programming beyond some horribly complicated CMD files and some very simple VB.

One of the commandlets is called "New-OwaVirtualDirectory". So I executed the command:

New-OwaVirtualDirectory -owaversion:exchange2007 -websitename "AA-Secured"

I watched the new OWA virtual directory show up in IIS manager while PowerShell plugged away. However after a little bit, it returned an error:

New-OwaVirtualDirectory : An error occurred while creating the IIS virtual directory 'IIS://server.domain.local/W3SVC/448843799/ROOT/owa' on 'SERVER'.
At line:1 char:24
+ New-OwaVirtualDirectory <<<< -owaversion:exchange2007 -websitename "AA-Secured"

Yes, I know I don't need to specify the version when executing this command - this is just one of the many ways I tried to get it to work.

In researching this issue, it seems that everybody's solution was to uninstall CAS (client access server - component of Exchange 2007), reinstall IIS and then reinstall CAS. Why would I want to do that? The original OWA listener works just fine.

If part of your job involves supporting and troubleshooting of Exchange environments, I really hope you follow the MS Exchange Team's blog. It's full of a lot of useful information. The part that specifically interested me was this article, titled "Supportability for multiple OWA/ Exchange Web Sites on Client Access Servers in Exchange Server 2007 and Exchange Server 2007 Service Pack 1" (quite the long title). However it was exactly what I was looking for.

1. If you are using Forms-Based Authentication for your /OWA and/or legacy (/Exchange and /ExchWeb) virtual directories, Microsoft supports a single Web site per Client Access Server. Further, the /OWA and legacy virtual directories must be in the same Application Pool (AppPool).
2. If you do not use Forms-Based Authentication, you can use as many Exchange Server-related Web sites as needed for your organization.
   However, Microsoft recommends that you use a Microsoft ISA Server 2006 server to handle Forms-Based Authentication for your various Web sites, in this circumstance.
3. If Forms-Based Authentication must be used on the Exchange Server 2007 computer *and legacy virtual directories are not used*, you can use multiple Application Pools (AppPools) for each Web site.
   Note: Lack of legacy virtual directories will prevent proxy to Exchange Server 2003 mailbox servers and prevent Entourage clients from synchronizing with the Exchange Server using the Exchange service.

Here was my reaction to these points:

1. Crap... We need forms-based authentication.
2. Who cares? We need forms-based auth and there's no way we're moving the firewall over to the ISA box (which we use for web proxy).
3. BINGO!

At this particular site, we only have a single Exchange server, which is 2007, and there's nobody using Entourage. So I used the following command to remove any legacy OWA directories:

Remove-OwaVirtualDirectory "exchange (default web site)"
Remove-OwaVirtualDirectory "public (default web site)"
Remove-OwaVirtualDirectory "exchweb (default web site)"

(I should mention that we didn't even have a public store at this site, much less users who use public folders via OWA, however I wanted to include it since most sites probably would have to remove that directory too)

After removing those other OWA virtual directories from the main site, I was able to execute the command successfully. Here's what IIS Manager and Exchange Manager looked like after all was said and done.





After making the new OWA virtual directory on the second site, we tested it to make sure it was fine on its own. Once we were confident everything was working, we locked it down with AuthAnvil's Web Logon agent, and modified the firewall so external users could only hit the new IP.