Exchange 5.5 > Microsoft Outlook Web Access HOWTO

1. Do I need to load IIS and OWA on every Exchange server in my organization?
   No. A single OWA server can service your entire org as long as there is RPC connectivity between the OWA server and every Exchange server you need it to serve.

   The best way to deploy OWA is to install it on one server that is dedicated to being a web server. There are many different ways to install this machine with the necessary network access while not compromising the security of your network.

   Scenario 1 - Inside the firewall. This is the simplest way to install OWA. Put it on the inside of your firewall and let all traffic to the server run through the firewall. The drawback here is that it will tax your firewall somewhat.

   Scenario 2 - Around the firewall. This is of medium complexity to setup up, but very flexible. Put 2 NICs in your server. Set a default gateway on the 'outside' card and not on the 'inside' card. Next, set in a static route to your network via the command line.

   'route -p add 192.168.2.0 mask 255.255.255.0 192.168.2.1', replacing the IPs with whatever is appropriate. This will allow the server to talk back into your network while ensuring good internet connectivity. In this scenario I would also think about shutting down unneeded ports on the outside interface. You can do this with NT by going into the advanced configuration of the TCP/IP protocol and choosing the 'security' option. This can be quite secure. Just remember not to keep secret information on the server since it's hanging out exposed on the internet. Shutting down all but the needed ports should help keep some of the bad people away.

   Scenario 3 - Outside the firewall. This is probably the most complex thing to set up as it requires heavy configuration of the firewall and of Exchange. You need to set Exchange to use only certain ports (check Technet or Knowledgebase for details) and open those ports on the firewall. Again, this leaves your server wide open so be cognizant of that.

   Which is best? Ask your network security expert what they feel the most comfortable with. If that person is you, discuss it with a Cuervo Gold magarita or two and see what you come up with. :)

   Once you've decided how to install the server, set it up. You'll need (as of this writing) NT Server 4.0 with SP4, plus the 'roll-up' hotfix and IIS3 or IIS4. The Exchange 5.5 version of OWA will NOT install without the roll-up hotfix and the asp fix (IIS3 only).

2. Can I mix versions of Exchange and OWA? And how about cross version compatibility for larger sites?
   The Exchange 5.0 version of OWA (technically this was called the Exchange Web Connector) will access Exchange 5.0 and above mailboxes reliably. You may have luck getting read-only access to Exchange 4.0 servers with this - it's not supported and iffy at best. The 5.0 with SP1 version of OWA has the same restrictions.

   The Exchange 5.5 version of OWA will reliably access both 5.0 and 5.5 based mailboxes with FULL functionality - including the Calendar!! That's right, you do NOT have to upgrade all your 5.0 servers to 5.5 to start using web calendaring. Again, though, 4.0 servers won't work.

3. When I tested this OWA thing it worked fine for my mailbox but when I went to show my boss she couldn't get in!
   I bet that you are a domain admin and she is not. The default installation of NT does not allow non-administrators to log on. You need to do the following:

   Open User Manager. Set the focus to the local machine (the webserver, NOT its domain). Go into the user rights dialog and grant the right 'Log on locally' to everyone. NOTE!!!! This opens your server up to anyone with a valid NT account to walk up to it and log in. Physical security of the server is called for here.

4. I did that and it's still flakey.
   Now you are probably having authentication problems.

   IIS has two main types of user authentication: Basic/Clear text and NT CHAP. Currently, only IE 3 or 4 (or Netscape Navigator/Communicator with a special plugin) can handle CHAP. Therefore, you need to look at who your users are and what level of control you have over them is.

   CHAP is the most secure, but you have to be able to mandate IE or provide the plug in for your Netscape users. Also, IE will by default simply pass through your current login when an application requests it. This can cause problems if you want to check your mail from someone else's desk and don't want to log them out.

   Basic/Clear text, on the other hand, is quite easy to set up but completely non-secure. The user id and password is transmitted in the clear. This could allow someone with a sniffer to capture IDs and passwords. To combat that, use SSL. (See your IIS docs for more on that).

5. I have that all straightened out and it still doesn't work unless the users type in their domain!
   This happens a lot in a master domain model, where the user accounts do not reside in the same NT domain as the web server. You can fix this easily.

   Under IIS 3.0: Open regedit. Under HKEY_LOCAL_MACHINE\System\Current Control Set\Services\W3SVC\Parameters, add a string value called 'DefaultLogonDomain'. Set its value to the name of the domain you'd like to authenticate against. Stop restart the Web Publishing service.

   Under IIS 4.0: You can change this in the management console. I'll try to remember where for version 1.1 of this file. :)

6. What a mess! Did all that and now I get 'Could not get Inbox' after I log in!
   Cookies cookies cookies! Turn 'em on, leave 'em on. Many ASP applications require the use of cookies to maintain state information (the Session.ID object is what we're after in this case). You could write a cookie detector script to give people a nice message when it doesn't work or you could just train your help desk. :)
7. Now I get an error which says 'No such interface supported' under IE 4.x.
   Reinstall IE. This is a common symptom of a not-quite-right IE install.
8. What about OWA and SSL encryption?
   Using SSL with OWA allows you to provide secure authentication and encryption for OWA users on almost any web browser, not just IE. SSL is installed by default with IIS. However, to avoid browser warning messages, you'll need a trusted site certificate, which you can get from VeriSign, Thawte, or Entrust. This costs money, but not too much. Their sites have easy-to-follow instructions on installing the certificate into your server. When you get the certificate installed, fire up a browser and load your OWA site, using https: instead of http: If you don't get any browser warnings, SSL is set up and ready to go.

   Next, you'll want to FORCE your users to use SSL when accessing your OWA site. You configure this by choosing "properties" in the IIS administrator for the 'exchange' directory. Make sure you chose the option to apply the setting to all subfolders as well. You can even force 128-bit SSL if all your users are technically savvy enough to install the 128-bit upgrades to their browsers (and they all live in the US or Canada). Now you'll want to turn on plain-text authentication for the OWA site in IIS administrator. This sounds scary, but since you're requiring SSL to the exchange site, all your passwords will be encrypted. Lastly, you don't want your users to have to remember to type 'https' to get at your site. So what you'll want to do is use IIS admin to set up a redirect in the root of your default web site that points to https://server.company.com/exchange. This way, all a user has to do is type in http://server.company.com and they'll be automatically redirected to your secured OWA site. If you have other stuff in the root of your server, set up a link from your main page to the secured site.

9. Making it look nice.
   Let's face it, the default pages Microsoft provides are just plain ugly. I highly recommend customizing them to fit your corporate image. While you're in there. turn off the anonymous access to your server by removing that section from the scripting. Personally I like to take the 'look feel' from the corporation's existing web pages. Especially if your company has an intranet. This makes the OWA system feel a little more comfortable to your users.