Business today is said to travel at the speed of light, unlike one particular thrill ride at a local amusement park that travels at the speed of fright (but then again, that’s a completely separate story). If you’ve personnel who travel frequently or large production (i.e. manufacturing) environments or a any of a thousand other things going on, you might want to consider using Outlook Web Access to allow your users to access their Exchange Server mailboxes-literally from anywhere in the world.
OWA: What’s It All About?
Outlook Web Access is certainly not a new feature introduced with Exchange 2000 Server; it’s been around for a while now. So, why am I writing about it now, after all this time? Despite that fact that the concept of OWA may not be new to the Exchange arena, OWA in its current form and state is new-and much improved. Come with me as we explore OWA from top to bottom and most everywhere in between. This will not be the article that gives you all of the solutions that you need to deploy OWA in an ultra-secure environment-that’s a series of articles in and of itself. This article is designed to get you started and up to speed on OWA in the event you choose to roll it out for your clients.
Accessing the Outlook Web Access server
When trying to access OWA, it is conceivable that one of two things will occur. If you are already authenticated in the domain, then you will not have to supply any additional credentials. If you are not (i.e. you are accessing OWA over the Internet), you will be asked to provide a standard set of credentials: user name, domain and password, which is been demonstrated in Figure 1 and Figure 2. After successfully authenticating (either way), you should see the OWA main window, as shown in Figure 3.
Figure 1 – Providing the required access credentials (from Netscape 4.08).
Figure 2 – Providing the required access credentials (from IE 5.01 SP2).
Figure 3 – Your Inbox in Outlook Web Access.
What you see in Figure 3 assumes that you are using at least Internet Explorer 5.01 or above. OWA will function in older browsers, without any modification or extra configuration, but the working environment will be less than spectacular. OWA is supported for the following browser clients:
- Netscape Navigator 4.08 and higher
- Internet Explorer 4.01 SP1 and higher
- Internet Explorer 5.01 and up
The OWA Session
When the OWA session starts, the OWA server will detect the browser being used and provide the appropriate user environment. New features that are supported when using the preferred client (IE 5 on a Windows 32-bit platform) include:
- A preview pane that allows you to preview messages without having to open them up.
- Right-click context menu options within OWA.
- HTML text editing when replying to or composing new messages.
- Drop and drag functionality that provides for moving documents between folders in your mailbox.
For cases where Internet Explorer 5.01 or above is not available, OWA still functions and is quite useable. Figure 4 shows the same OWA connection, but this time made via Netscape 4.08 (also the source of the authentication shown in Figure 1).
Figure 4 – OWA via Netscape 4.08.
In this case, the left pane is static and shows the navigation structure you have. The right pane displays the selected folder view, message, appointment, etc. Clients accessing the OWA server, if not Internet Explorer 5.01 or above, should at least be HTML 3.2 and ECMA compliant.
Regardless of what browser you use to access the OWA server, you will still have somewhat less functionality than if you were accessing the Exchange Server via a full-blown Outlook 2000 client. You will lose the ability to spell check, work offline, create or modify Outlook rules, send messages for deferred delivery, send messages with an expiry date, move messages between public and private folders or work with digitally signed or encrypted messages. The last item, however, is a limitation of the browser itself, not of OWA and thus may be supported in the future.
Digging-in With OWA
You can use the following example URLs to reach different portions of your Exchange public/private folders and shortcuts can be created to specific documents or locations as you desire.
http://servername/exchange/ – Logs into the OWA server
http://servername/exchange/user/ – Logs into the OWA, specifying a user
http://servername/exchange/user/folder name – Logs into OWA, specifying the user and initial folder view, such as calendar, contacts, journal, etc.
http://servername/exchange/user/inbox/file.eml – Logs into OWA, specifying the user, initial folder view and a specific email item to view.
http://servername/public/ – Opens the top level Public folder.
By default, OWA is installed with Exchange 2000 Server and enabled for all Exchange users. You cannot choose not to install OWA, but you have two options for controlling access to OWA should you desire. You can either choose to stop OWA all together or you can disable OWA access on a user-by-user basis. Both methods will be explored and explained.
Disabling Outlook Web Access for a server
If, after installing Exchange, you decide that you do not want to run Outlook Web Access, you will need to stop the HTTP Virtual Server that Exchange Server is utilizing. Doing this will disable HTTP services for Exchange. If you have not configured additional Virtual Servers on that server, you will be disabling all HTTP services on that server. To disable the Exchange Virtual Server, follow the steps outlined below:
1. Open the Exchange System Manager.
2. Expand the nodes (as shown in Figure 5) until you get to the Exchange Virtual Server for the server of concern.
3. Right-click the Virtual Server and select Stop. The icon will now show a red X over it.
Figure 5 – Disabling the Exchange Virtual Server.
Now when a user tries to connect to OWA using that server, they will receive the standard 404 error, as shown in Figure 6.
Figure 6 – OWA cannot be accessed on this server.
Disabling Outlook Web Access for a specific user
As I mentioned previously, OWA is enabled by default for all Exchange users. You can, however, disable OWA for a specific user if you need to. In this way, other users can still use OWA unaffected. To disable OWA for a specific user, follow the steps outlined below:
1. Open Active Directory Users and Computers.
2. If not already select, enable Advanced Features by clicking View | Advanced Features.
3. Expand the nodes until you have located the user of concern.
4. Right-click the user and select Properties.
5. Switch to the Exchange Advanced tab and click the Protocol Settings button.
6. From the Protocols page, click HTTP.
7. From the HTTP Protocols Detail page, deselect the Enable for mailbox setting, as shown in Figure 7.
8. Close out all properties pages and the Active Directory Users and Computers console.
Figure 7 – Disabling Outlook Web Access for a single user.
Users with HTTP access disabled will get a 403 error, as shown in Figure 8, when they attempt to connect to the OWA Server.
Figure 8 – HTTP access prohibited.
Note that you will need to make sure that users log out of any current sessions before the change in permissions can be applied.
We’ve covered the basics of Outlook Web Access in this article. There are literally hundreds of situation that you may encounter, however, that require some sort of custom implementation or security solution. Those will be approached later, one at a time, in subsequent articles. If you have a suggestion or a story to tell about your own implementation of OWA, please feel free to send me an email and let me know. I’d like to hear from you about how you are implementing OWA.