Microsoft Outlook Web Access (OWA) is a tightly integrated component of Exchange 2000. In fact, as part of the default setup of Exchange 2000, no customization is needed to run OWA. However, if your organization requires more performance, reliability, and security than an “out of the box” OWA solution provides, a front-end server may be just what you need. I’m going to show you how to go beyond the basic setup of Exchange 2000 OWA to explore ways your organization can leverage the key benefits of a front-end/back-end (FE/BE) OWA architecture.
Using an FE/BE topology
Are you already running multiple Exchange 2000 servers in your organization? If so, Microsoft recommends using the FE/BE server architecture to deploy OWA. With this topology, the front-end Exchange 2000 server sends HTTP requests to a back-end Exchange 2000 server running OWA. The front-end server first performs a lookup in AD to determine which back-end server should receive the request and then relays the request to the appropriate server.
The obvious benefit here is the single, consistent namespace the front-end server provides to users. Users don’t need to remember URLs specifying exactly which servers their mailboxes are on. Additionally, with a single namespace, mailboxes can be moved between back-end servers and users can still use the same URL.
The other benefit is seen when allowing OWA access via a secure firewall connection or DMZ. As Figure A illustrates, only the front-end server is exposed on port 80 to the Internet. Since this server does not contact user mailboxes or data, it provides an additional level of security.
|An FE/BE topology|
Any server running Exchange 2000 Enterprise Edition can become a front-end server. The only change needed is the selection of the This Is A Front End Server check box in the server’s Properties dialog box, shown in Figure B.
|Configuring a front-end server|
After making the change, you must restart the Exchange and IIS services or restart the computer. The change essentially tells the Exchange 2000 server to redirect all HTTP traffic to a back-end server that contains the user’s mailbox.
As a general rule, one front-end server is recommended for every four back-end servers. Of course this is just a rule of thumb. The actual number of front-end servers needed will depend on the number of users, the type of users (light vs. heavy), and the average length of sessions. Front-end servers do not need large or particularly fast disk storage but should have specs similar to a Web server, including fast CPUs and adequate memory.
Securing communication between servers
The front-end server handles authentication in one of two ways. Either the server is configured to authenticate users, or it is set up to forward the request anonymously to the back-end Exchange 2000 server. The recommended configuration is to have the front-end server authenticate users.
Exchange 2000 front-end servers support only HTTP 1.1 basic authentication between client computers and front-end servers, as well as between front-end and back-end servers. Basic authentication allows for just a weak form of encoding when sending usernames and passwords across the network, so the use of SSL is highly recommended.
This is where another benefit of FE/BE architecture comes in. When using SSL, front-end servers can handle all encryption and decryption processing, which improves network performance by removing SSL processing tasks from back-end servers. As an added measure of security, you should make SSL connections to the front-end server mandatory by disabling access without it, as we’ve done in Figure C.
|It’s best to require SSL on the front-end servers.|
You should also note that HTTP communication between the front-end and back-end servers is not encrypted. Front-end servers do not support Windows Integrated Security (which includes both NTLM and Kerberos authentication). They also do not support using SSL to communicate with back-end servers. All of these factors lead to the conclusion that SSL on the front-end is the best solution.
OWA logon for front-end servers
Typically, users must enter their username in the format domain\username when logging on to a front-end server. However, you can configure the front-end server to assume a default domain so that users do not need to type their domain name. Just modify the Exchange and Public virtual directories and manually enter the default domain name, as shown in Figure D.
|Entering a default domain name for user logons|
After making this change, make sure that the System Attendant service is running so that the configuration settings replicate from the directory to the IIS metabase or simply restart Exchange System Attendant to force replication. After replication is complete, users can log on with just their username and password; no domain name is required.
An additional option for authentication is to configure a User Principal Name (UPN) logon for users. This allows users to enter their e-mail address as their username. To configure UPN, enter a backslash in the Default Domain text box shown in Figure D. After you configure this in the properties of the virtual directories on all front-end and back-end servers, users can authenticate using email@example.com as their username. (Note that Exchange SP1 is recommended if you decide to use this feature.)
Service pack install order
The order in which you apply Exchange 2000 service packs in an FE/BE OWA architecture is important. Always remember to upgrade every front-end server in the organization before you upgrade any back-end servers. This is because of the way OWA’s templates and controls were designed. A problem arises when the servers run different versions of service packs.
If a template on a back-end server references a control on a front-end server, and the front-end server is running a previous service pack, the control that the back-end server is referencing might not exist. As a result, OWA won’t work for users whose mailboxes are on the upgraded back-end server. Just make sure that you upgrade all front-end servers first so that users see templates from the back-end server. These templates reference the previous versions of the controls, which still exist on the front-end server because the files are versioned and not removed in an upgrade.
When deployed properly, an OWA solution using front-end/back-end architecture can be more reliable, result in greater performance, and provide tighter security than the generic setup offered by default on Exchange 2000. Use this topology to take your OWA to the next level.
Subscribe to the Developer Insider Newsletter
From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays