Introduction
When MS Exchange 5.5 was first introduced, having a permanent connection to the Internet was much less common than it is now. Consequently, Outlook Web Access (or OWA for short) was less likely to be part of the standard Exchange installation. Now that more and more Exchange Admins are discovering just how useful OWA can be, many are adding its functionality to their installations. Nowadays, the chances are quite good that they will be looking to install it on an IIS server running on Windows 2000. In this situation, OWA installation is rather less straightforward than you might hope.
For starters, you’ll find that you are unable to install it on Windows 2000 Professional. There may be no technical reason that OWA will not run on any IIS server, but unfortunately the Exchange setup program seems to think otherwise.
Procedure
This, then, is the starting point for our installation; you’ll need a Windows 2000 Server that also has MS Internet Information Server installed and running. Whether or not you intend to install it on an existing Exchange server, or on a separate IIS server depends on the anticipated workload (and whether you have a spare server, or not), but normally OWA will be installed on a separate server.
Many Exchange Admins wishing to install OWA believe that it is a separate product, or that you have to obtain it separately from somewhere. For the benefit of those that don’t know where to find it; it’s actually an option in the Exchange 5.5 Setup program. So, insert your Exchange 5.5 CD and run the setup program. The first thing you’ll see is the warning message displayed in figure 1. You can safely ignore this message – Exchange 5.5 runs perfectly happily under Windows 2000 as long as you apply a recent Service Pack to it.
Fig. 1 – The Warning message from Windows 2000.
Okay, so you clicked the Run Program button, and if you are especially brave you may even have checked the ‘Don’t display this message’ checkbox. The next two dialogs you’ll see will depend upon whether or not you are installing on an existing Exchange Server. If you are installing on a separate IIS server that is not already an Exchange server, you’ll see the Installation type dialog box shown in figure 2. In this case, you need to click the Complete / Custom button, and select only the Outlook Web Access option as shown in figure 3.
Fig. 2 – Choosing the installation type.
Fig. 3 – The selection for a separate OWA installation.
If you’re installing onto an IIS server that is an existing Exchange Server, then you’ll see the Add / Remove dialog as shown in figure 4. Select ‘Add / Remove’ to reveal the dialog box shown in figure 5. What you see selected here will depend upon your existing Exchange configuration, but since you’re adding OWA, you need to make sure that that particular option is selected. If it is already selected, then you already have OWA installed!
Fig. 4 – The Add / Remove installation dialog.
Fig. 5 – The OWA selection to modify an existing installation.
After clicking the Continue button, the OWA HTML source files will be copied to your server’s fixed disk, usually in C:\Exchsrvr\Webdata , and you will need to supply the machine name of your Exchange Server when necessary. The installation is now almost complete, but there are still a few extra tasks to take care of.
Fig. 6 – Specifying the Exchange Server.
The first is a fairly simple task: To make sure that your users don’t need to supply a login of the form
Fig. 7 – Specifying the Default Authentication Domain.
The second task is to install a recent Exchange Service Pack. This is essential – OWA will be completely unusable without it. If you try, you will see the following error message displayed in your browser:
Microsoft VBScript runtime (0x800A01A8)
Object required: ‘Application(…)’
/exchange/USA/logon.asp, line 12
The final task is to make sure that non-admin users will be able to open their mailboxes in OWA, and for this they will need the Log On Locally right on the server itself. The easiest way to find out if they have this right is to invite a non-admin user to log in at the server console. If they can, then they can use OWA without any domain security problems. If not, you will need to give the Everyone group this right. On a non-Active Directory machine you can specify this in the Control Panel app. for ‘Local Security Policy’, otherwise, you may need to specify it in ‘Domain Controller Security Policy’. The layers of security precendences can actually make this task rather difficult, and the fact that it sometimes takes a few minutes for your changes to take effect does not help matters. You will need a systematic approach to discover the correct combination for your domain security configuration.
