And minimize the security risks of Internet email access

I recently embarked on an unusual weight-loss program: I stopped taking my laptop on short business trips. With Microsoft Exchange 2000 Server's Outlook Web Access (OWA) 2000, I can use most of Outlook's features from wherever I can access a reasonably recent Web browser. Following a few configuration tips and access strategies can help you realize the same benefits.

Be Informed
The first step toward maximizing OWA 2000's advantages is knowing what the software can and can't do. OWA 2000 offers most of Outlook's major features, but it doesn't support Outlook's Tasks or Journal. Nor does OWA 2000 include a spell checker (although Messageware and CompuBridge sell solutions that work pretty well). Keep in mind that OWA 2000 doesn't replace Outlook; it provides client services to users who can't, don't, or won't use Outlook on Windows or Macintosh.

To access OWA 2000, you need a browser that supports HTML frames and JavaScript. OWA 2000 on Microsoft Internet Explorer (IE) 5.0 and later gives you the most Outlook-like experience. However, I've used OWA 2000 on IE 4.0 and later, Netscape Navigator 4.08 and later, Opera Software's Opera for Windows and Opera for Macintosh, and Alexander Clauss & iCab's iCab browser (for Macs only). When you enable basic (i.e., text-only) authentication, OWA 2000 also works with Pocket PC's Pocket Internet Explorer (PIE). You can also use OWA 2000 with a variety of Internet appliances.

Downloading the Exchange multimedia ActiveX control lets you compose rich-text messages. Open OWA 2000, then click the Options icon in OWA 2000's left pane. In the Options window's E-mail section, click Download. (Because the control is an ActiveX control, IE security restrictions on some machines might not let you download it.)

Be Secure
Speaking of security, if your platform supports Secure Sockets Layer (SSL), I recommend that you enable SSL on your Microsoft Internet Information Services (IIS) 5.0 server (which serves OWA 2000 pages). SSL encrypts all traffic to and from the Web server. Thus, data can't be read or modified in transit—essential protection when users are passing their usernames, passwords, and sensitive information to your server. TCP port 80 typically carries plain HTTP traffic, but SSL traffic (identified by the https prefix in a URL) uses port 443. You should configure the server to permit OWA 2000 use only through the secure port.

The risk of intercepted credentials might not seem large until you consider how and where a user is likely to use OWA 2000. Say I'm flying to New York: I'll be at three airports, a hotel, and several client sites. Instead of dragging out my laptop to check my email, I—like thousands of other travelers—will use a public access point. Because these easily accessible Internet access points are in high demand and a large volume of valuable information passes through them, intruders are more likely to sniff these service points than your home or office LAN connections.

To enable SSL on your IIS machine, use IIS's Web Server Certificate Wizard to generate a certificate request. You access the wizard from the Microsoft Management Console (MMC) Internet Information Services snap-in. Open the Properties page for the Web site that serves OWA 2000 pages, then click Server Certificate on the Directory Security tab and follow the wizard's prompts to create a certificate request. Send the certificate request to the Certificate Authority (CA) of your choice. To install the certificate that the CA issues, run the Web Server Certificate Wizard again.

You enable SSL from the Internet Information Services snap-in. Open the Default Web Site Properties page, then click the Web Site tab. In the Web Site Identification control group, click Advanced, then verify that the dialog box's Multiple SSL identities for this Web Site field shows the site's IP address on port 443. (You might need to enable this port on your firewall.) Finally, check that you can connect to https://yourservername.

After SSL is ready to go, you can make some useful changes to it. First, I highly recommend that you require the use of SSL for all communication with your Web server; putting a strong lock on your door is useless if a thief can climb in through the window. To force SSL use, click the Directory Security tab of your Web server's Properties page, click Edit in the Secure Communications option group, then select Require Secure Channel (SSL). After you apply the change, test it by trying to connect to http://yourservername. You should see an SSL required error message (error code 403.4). For details about enabling and enforcing SSL use, see the IIS 5.0 documentation and the Microsoft article "HOW TO: Enable SSL for All Customers Who Interact with Your Web Site" ( Another helpful resource is Joseph Neubauer, "Secure Client Communications with SSL,", InstantDoc ID 22153.

A potential price you pay for requiring the use of SSL is an increase in Help desk calls from users who type http:// instead of https://. To solve this problem, you can install code on your server that automatically redirects users to the SSL-protected channel from the error page that appears when they try to access the insecure URL. The code in Listing 1 rewrites your IIS machine's 403.4 error code to redirect users' browsers to the secure channel. Copy Listing 1 to a file you create in your Exchange 2000 server's \inetpub\wwwroot\owaasp directory (the filename isn't important, as long as you can remember it and it has an Active Server Pages—.asp—extension). Then, from Internet Services Manager (ISM), open the Custom Errors tab of the Exchange virtual directory's Properties page. Double-click 403.4, and in the resulting Error Mapping Properties dialog box, specify that you want 403.4 to return a URL of /owaasp/yourfilename.asp. Then stop and restart the IISAdmin service. Because stopping the IISAdmin service stops all Exchange services, perform this step when an outage won't be too inconvenient.

Enable Password Changes
Reusable passwords are risky, so setting password-expiration intervals is a good idea. However, expired passwords present a problem to users who contact your servers only through OWA 2000. By default, users can't change their passwords over the Internet. (Microsoft built in this restriction to reduce the security vulnerabilities of the average Windows installation.) However, enabling Web-based password changes is fairly simple.

First, your Web server needs to be SSL-enabled. You then need to make a few IIS 5.0 configuration changes. The Microsoft article "XWEB: How to Change OWA Passwords Through IIS" ( describes these changes in detail. In brief, on the Web server, create a new virtual directory that points to the \system32\inetsrv\iisad-mpwd files that ship with IIS 5.0. Then, use the adsutil script (under \inetpub\adminscripts) to alter the value of a metabase flag that tells IIS 5.0 whether the Web-based password-changing functionality is enabled. (If you're using OWA 2000 on a clustered system, you need to follow a different procedure. See the Microsoft article "XWEB: How to Enable the Change Password Function in Exchange 2000 OWA Clustering" at

Be Multilingual
One helpful but relatively unknown feature is that OWA 2000 lets IIS serve up language-specific versions of its interface. When you perform a default installation of OWA 2000, you install the files for many languages. Suppose you travel to a country whose language you don't speak and you want to check your email from a client site, but the site doesn't let visitors connect their laptops to the LAN. No problem: Find a machine with IE, start IE, and select Internet Options from the Tools menu. Then, on the General tab, click Languages to bring up the Language Preference dialog box. Select the language you want to make available and move it to the top of the list. Then, enjoy your email, but don't forget to remove your language or move it back into its original location in the list when you're finished.

Get SP1
Exchange 2000 Service Pack 1 (SP1) includes some worthwhile enhancements to OWA 2000. My favorite is the feature that lets you recover deleted items—just open OWA 2000's Options page, go to the Deleted Items section, and recover away. SP1 also adds support for 13 new languages.

SP1 also fixes two flaws: the inability to add attachments to Public Folder items and a bug that causes OWA 2000 to use a server's NetBIOS name instead of its Fully Qualified Domain Name (FQDN). This bug makes accessing Public Folders difficult for remote users unless the network has a front-end­back-end topology. For OWA 2000 to work properly, you must install SP1 on your front-end servers before installing it on your back-end servers.

Lose Weight Now
Not every user will be able to drop his or her laptop weight, but those who can will certainly appreciate the changes you can make to maximize OWA 2000. Applying simple configuration changes and teaching users easy access tips can help you offer greater security and better functionality to your Exchange users.