Connecting Outlook Web Access 5.5 To Exchange 2000



Connecting Outlook Web Access 5.5 and Exchange 2000




Introduction



Why on earth would anyone want to try to connect MS Exchange 5.5 Outlook Web Access (OWA for short) to an Exchange 2000 server? Well, quite a few people have tried and here’s why: In Exchange 5.5, you could have your main Exchange services running on one server, and then you could install OWA on another server, possibly an IIS server in a de-militarized zone (DMZ). This was, and still is, a very popular and sensible configuration. With the arrival of Exchange 2000, administrators discovered that it was no longer possible to install Exchange and OWA on separate servers. The official way to get OWA on its own server is to install two Exchange Enterprise servers in a Front-end/Back-end (FE/BE) configuration. Naturally, this seems rather excessive to some people, and remembering the OWA 5.5 way of doing things start looking for their old Exchange 5.5 CD and attempt to connect the older OWA to their new Exchange 2000 server, regardless of its somewhat inferior interface.



The usual way to install OWA 5.5 on a separate IIS server is to run the Exchange 5.5 setup program, select the Custom Option, choose only the OWA component, and point it at your Exchange server. Unfortunately, if you try this with OWA5.5 / Exchange 2000 you get a rather meaningless error message, as shown in figure 1.






Fig. 1 – NOT a helpful error message.




But why should this be? OWA 5.5 is based upon CDO v1.21, which Exchange 2000 still supports, so in theory this should work. It turns out that while CDO v1.21 works with Exchange 2000, the Exchange 5.5 setup program doesn’t. So, we need to find a way of getting OWA 5.5 on a server in spite of this obstacle.




Procedure



I must first point out that the procedure described here is presented as an experiment only. Connecting OWA 5.5 to Exchange 2000 is not a supported configuration, and the licensing implications are debatable.



In order to install only the OWA 5.5 component on a server when it can’t be connected to a live server, it is necessary to be a little devious. You need to do a full installation of Exchange 5.5 onto the server (creating a fictitious Organization and Site), including the OWA option, and then uninstall everything except OWA. This ‘orphaned’ OWA installation can then be connected to a live Exchange installation by modifying a few registry entries. That’s the theory anyway. Does it work in practice?



Let’s perform the full installation. Here, this is being done on a MS Windows NT4 / IIS server that is configured as a member server. It has the usual pre-requisites for OWA 5.5, namely; IIS 4 from the NT Option Pack, and the latest NT Service Pack re-applied after the Option Pack installation.



First, we need to run the Exchange 5.5 setup program, selecting the Custom installation type as shown in figure 2.






Fig 2. Selecting the installation type.




Next, the OWA option is selected from the list of application components as shown in figure 3. This option is normally not selected in the default installation.






Fig.3 – Adding the OWA option to the installation.




Then, after entering the product serial number, and accepting the license agreement, the option to create a new Organization and Site is selected. It is important to remember that this is a fictitious Organization and Site, and it will be entirely removed in the second stage of the procedure. Figure 4 shows the creation of the new Organization and Site.






Fig. 4 – Creating a fictitious Organization.




Then, the setup program asks for the Exchange Services account. The Services will be removed later, so the choice is not too important, but it is sensible to choose one with elevated privileges on the machine so as to avoid possible errors at the end of the setup program. After this, the setup program copies the files on to the server and quits. There is little point in running the Optimizer when in invited to do so.



Outlook Web Access 5.5 requires the application of the latest Exchange 5.5 Service Pack, so now is a good time to apply it; it may fail if we leave it till later.






Fig. 5 – Apply the latest Exchange 5.5 Service Pack.




That’s the first part done. Now, we move on to the second part. This is where we remove everything we’ve just installed except the OWA component. To do this, we need to run the Exchange setup program as before, but this time it looks rather different (figure 6), since there are Exchange components already present on the server.






Fig. 6 – The Add / Remove setup program.




Here we need to choose the Add / Remove option so that we can deselect all of the components except OWA as shown in figure 7.






Fig. 7 – The OWA installation option selected.




Select continue and confirm the removal of the other options. The setup program will remove most of the files and services that it added earlier. There is no need to re-apply the Service Pack when it has finished.



Okay, now we have OWA 5.5 on the server, and no other Exchange components. Of course, if we try to access it now, there is no chance of it functioning correctly. What is needed is to change a few registry entries to make it point to the Exchange 2000 server. We first back up the registry (very important!), start regedit, and navigate to the following registry key:



HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB



This will probably look something like figure 8:






Fig. 8 – The MSExchangeWEB registry key before modification.




We need to change the values of Enterprise, Server, and Site to point to the correct Organization, Server and Site. It should look something like figure 9:






Fig. 9 – The MSExchangeWEB registry key after modification.




A few final changes are now needed; because this is OWA 5.5 we’re talking about, we need to give the ‘Everyone’ group the ‘Log On Locally’ right on the server, otherwise only Administrators will be able to use it. Also, because this is a member server, we need to set the Default Authentication Domain for the Virtual Directory in IIS Manager. Without this, we would need to log on with DOMAIN/USERNAME because IIS would otherwise try to authenticate us against its local SAM database.



And that’s it. Does it work? Well, the proof of the pudding (it is said) is in the eating. Let us try to access the newly installed OWA Virtual Directory. The next two figures show the familiar yellow logon screen, followed by an Inbox display.






Fig. 10 – The OWA 5.5 Logon screen.







Fig. 11 – The OWA 5.5 Inbox.




It seems to work as expected – of course; this is just a superficial test and I would not be very surprised if some of the functions did not work as expected.



If anyone is interested in trying this for themselves, I must reiterate that this is definitely not a supported OWA configuration. You must only attempt this if you are confident of your abilities – you must not expect to receive any technical support from Microsoft if anything should go wrong.




About the author:



Lee Derbyshire BSc (Hons), MCSE is a full-time IT Professional living in the UK. You can visit his Web page at www.leederbyshire.com .


Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top