From: Markham, Ontario
I've gotten a lot from this site, so I wanted to return something to the group. I came upon this site looking for answers for 4 things regarding OWA and although I found the answers, it was quite the task finding all the little tidbits of information here/there. So I just wanted to summarize what I found and present it here so that it might help someone else.
The 4 things I was looking for were:
How to install OWA outside of the default web site.
How to enable SSL for OWA.
How to enable Forms Based Authentication for OWA.
How to redirect HTTP to HTTPS for OWA.
First, let me say up front that I don't want any credit for the information I am posting. Most of it was here already, but in a very disjoint manner spread out across several articles and posts. All I am doing is summarizing a bunch of information I have found. I have specifically tried this stuff out on OWA installed on SBS2003. There may be some minor differences for other versions of Exchange.
By default, OWA is installed under the default web site. The problem with this under SBS is that other services, such as Terminal Services, are also installed under the default web site. So in order to isolate usage to only OWA, it might be preferable to create a separate site for OWA.
In order to create another OWA site, you need to create a new HTTP Virtual Server in Exchange System Manager (ESM) under Servers/Protocols. Every HTTP Virtual Server is represented in IIS as a new Web site, but you don't need to create the site in IIS.. Behind the scenes, there is a DS2MB service which is replicating the settings under the Virtual Server to the IIS configuration, so when you create the HTTP virtual server, it is automatically created in IIS. This is important to know because if you change something in IIS, it can potentially be overwritten by the replication (ie. it is a one way replication). For example, if you change the IP number in IIS for an HTTP Virtual Server, the change will immediately take effect, but after some time, you will see it revert back to the old IP number.
When creating the Virtual Server, the general settings are very similar to creating a new site in IIS. Just some things to note:
1. In order to set the SSL port, you need to blank out the host header name
field and TCP port field, otherwise, the SSL port field remains disabled.
2. Because of #1, you need to create multiple IP entries if you want both non-SSL and SSL traffic to your OWA.
To Create a New OWA Site outside of the Default Web Site:
1. Create new HTTP Protocol virtual server in ESM.
2. When creating the server, ensure that a TCP Port 80 is defined along with a valid (unique) IP address. Specify a host header if you want/need.
3. Under the new site, create a new Virtual Folder called Exchange connected to the SMTP mailboxes and another Virtual Folder called Public connected to Public Folders.
4. Wait a few minutes and then open the IIS Admin tool. You should see the new HTTP Virtual Server listed as a new site.
At this point, you should be able to login to the site from a browser. If you have a DNS host name defined for the IP you configured, you should be able to connect using http://yourDNShostname/ using BASIC authentication (http://yourDNShostname/exchange should also work). Of course, this is not ideal for production, but its a good stage to just test out how things are going.
Side Note: I don't believe you technically need the Exchange virtual folder, except, I have found that the logon/logoff scripts within OWA expect the existence of this folder. So if you don't have it, you will get an error when you logoff and try to login again to OWA. But the first time you login, it will work fine. For consistency sake, I would just create the virtual folder. Also, if you need additional features like OMA, etc... you will need to create these other virtual directories. You can use the default HTTP Virtual Server as a reference.
To SSL Enable Your OWA Site:
1. In IIS Admin, install a security certificate for the OWA site you created either using Certificate services or a 3rd party Certificate Authority. The following knowledgebase article can be helpful although it was written for Exchange 2000, (KB320291).
2. Back in ESM, under the advanced button for IP configuration, click Add to add an additional identity. Use the same IP number as before. Make sure the TCP port field and host header field are blank. The SSL Port field should become enabled.
3. Enter 443 into SSL port field. Click OK.
After a few minutes you should see the SSL settings replicated to your IIS website. You should now be able to access the site using https://yourDNShostname/.
FYI, there is an excellent article with much more detail about enabling SSL on OWA at http://www.msexchange.org/tutorials/Securing-Exchange-Server-2003-Outlook-We b-Access-Chapter5.html . It was written by Henrik Walther (who I'm sure most people here know).
To Enable Forms Based Authentication For Your OWA Site:
Enabling Forms Based Authentication (FBA) on your site is pretty simple, except you need to keep in mind 2 things. First, make sure SSL is configured and working BEFORE you check off the FBA enable box (under the ESM HTTP Virtual Server Properties, Settings tab). The second thing to do is restart IIS after enabling FBA. If you do this, you should have no problems using FBA.
Forcing SSL For Your OWA Site:
The way the default web site works is that if you go to http://defaultwebsite/exchange, it will redirect you to https://defaultwebsite/exchange, so that you will always connect using SSL. This can be useful because people are more used to typing http rather than https, so it can prevent someone from unknowingly accessing OWA in the clear. This is not hard to do, but it takes a couple of tricks to make it work seemlessly, like in the default web site.
1. In IIS, go into the properties for your OWA site and under the Directory Security tab, click Edit to acces the Secure Communications properties. There should be a checkbox saying Require Secure Channel (SSL). Check off the box and enable the option. Allow this option to propagate to all virtual directories under the web site.
2. By doing #1, if you try to access http://yourDNShostname/ you should now see an error message saying that SSL is required for connection (error 403.4 I think). In order to redirect the site, you have 2 methods you could use. First method is to create an HTML or ASP page which will automatically redirect you to the https site. Then you can change the error message for 403.4 to that HTML/ASP page so when someone connects by http:, IIS will show that page which will then redirect the user to https:. For more information on this, take a look at KB article 555126 http://support.microsoft.com/default.aspx?scid=kb;en-us;555126.
3. The other way to do this is a little more convoluted, but I think its a little easier to implement. First, under your OWA site, add a host header to your port 80 IP number (the header can be anything BUT it should not be a real DNS host name, something like "notreal.mydns.com"). The reason for this is that you want the OWA site to ignore port 80 requests, but if you try to remove the port 80 IP all together, IIS doesn't like it. By adding an invalid host header, there is no way a user could ever connect by port 80. Second, create a new web site in IIS (call it OWA Redirect) and assign it the same IP number as your OWA site and give it a host header of 'yourDNShostname' (whatever DNS host name you users are using to connect to OWA). For this site, give it anonymous access and under the Home Directory properties, set this site to redirect to https://yourDNShostname/. By doing this, anyone connecting by http://yourDNShostname will connect to the redirect site which will send them to the https site.
I like the second solution a little better because it is entirely encompassed within IIS and is easy to reverse (ie. just delete the redirect site). It also does not involve creating HTML pages or messing with the error message (BUT either method is perfectly fine and I believe there is no technical adavantage to either method). For some, having the extra redirect web site might look silly, so they will prefer the first method. [As an aside, you might have seen my other post about how the default web site does the redirection. AFAIK, the default web site doesn't use either of these tricks to redirect http to https. If you know it does this, I would love to know.]
I hope someone can make use of the above information. I find OWA a little hard to understand because it is so integrated with IIS and yet it is not entirely clear what Exchange does and what IIS does. While there is a lot of information on the net regarding OWA, its hard to sometimes put it all together.
[ March 10, 2005, 07:35 PM: Message edited by: GQUEUE ]