Steve Luzynski's Outlook Web Access FAQ Planning for OWA Do I need to load IIS and OWA on every Exchange server in my organization? Can I mix versions of Exchange and OWA? And how about cross version compatibility for larger sites? I installed it and it doesn't work! 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 did that and it's still flakey. I have that all straightened out and it still doesn't work unless the users type in their domain! What a mess! Did all that and now I get 'Could not get Inbox' after I log in! Now I get an error which says 'No such interface supported' under IE 4.x. Making it look nice Section 1 - Planning for OWA Q: 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 SP3, 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). Q: 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. Section 2 - I installed it and it doesn't work! Q: 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. Q: 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). Q: 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. :) Q: 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 requires 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. :) Q: 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. Section 3 - 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. If you'd like to see an example, check out http://webmail.utilicorp.com. You won't be able to actually log in, but it does show a customized site that operates under SSL. Compiled by Steve Luzynski Updates and comments: mailto:[email protected]. Disclaimer: The advice given in this FAQ may not be directly from Microsoft. Official advice and help on Web Access from Microsoft is available in the documentation (README files included) and through MS Product Support Services (PSS). If you are expreiencing a major problem with Web Access and it is not answered in this FAQ or on the mailing list, it is suggested that you contact Microsoft PSS to resolve your problem.