Simplify access for your users
Outlook Web Access (OWA) for Exchange Server 5.5 provides a quick and convenient means for accessing email through a Web browser. A prerequisite for OWA is Microsoft IIS. IIS consists of Web sites that contain virtual directories that point to files' physical locations. Although one IIS server can host multiple Web sites, no two Web sites can occupy the same IP address and port number combination. If they do, individual Web sites will fail to start. A default configuration of IIS contains one Web site—the Default Web site. To achieve optimum integration with IIS, Microsoft designed OWA as a virtual directory within the default IIS site.
Thus, you can access OWA from your browser by entering http://IIS
servername/exchange. If you add a Fully Qualified Domain Name (FQDN) to your DNS for your IIS server, you might end up with a URL like http://
webmail.xyz.com/exchange. If you add Secure Sockets Layer (SSL) through Microsoft Certificate Server or a commercial certificate authority such as VeriSign, you get https://webmail.xyz
.com/exchange.
To simplify user access to such a powerful tool as OWA, you can eliminate the need to enter a complex URL on a browser's address line by making the OWA URL a hotlink on a corporate Web page. Users need only access the Web page and click the link. Companies that prefer to establish OWA as a separate Web service can provide access to OWA through one URL.
Creating access to OWA through a URL lets you to tell the president and CEO of your company that they can access email from the Web by entering only webmail.xyz.com on the address line of the browser and entering their network credentials when prompted. All other mechanisms of this communication, such as the virtual directory and security, occur under the covers.
What's the easiest way to create one URL for OWA with the least effort and for the most gain? Neither IIS nor OWA in Exchange Server 5.5 Service Pack 3 (SP3) provides this capability in a built-in fashion. You can't choose to establish one URL when you install OWA. Nor does IIS let you configure your IIS server for multiple Web sites. Because Microsoft designed OWA to integrate optimally within the IIS default installation and coded OWA to exist as the /exchange virtual directory within the default Web site, you can't relocate the exchange virtual directory to the root of the Default Web site.
However, you can redirect a URL to the default /exchange virtual directory through IIS. This redirection can also take into account SSL security and can include the https prefix.
I explain two ways to accomplish this redirection without changing the default location of Exchange OWA files or modifying any code or the Windows NT Registry. The methods I present here work for both single-site and multisite Exchange implementations. However, if you have multiple NT domains with trusts, you can set only one domain as the default NT logon domain. Users accessing OWA in other NT domains must preface their username with their home NT domain (NTdomain\username). Slower linked sites will, of course, yield proportionately slower response times. As always, practice good predeployment testing to adequately flush out potential problems.
Preliminaries
The information in this article is specific to installations of Exchange Server 5.5 SP3. I assume that you have successfully installed and configured OWA in its default configuration and that you're familiar with the Internet Service Manager (ISM) interface in Administrative Tools in IIS 5.0 and in the NT 4.0 Option Pack menu in IIS 4.0. Further, I don't delve into the specifics of how to make DNS entries beyond saying that you need an FQDN mapped to the IP address of your IIS server.
I don't include detailed configuration information for accessing OWA through a firewall. Essentially, you need to decide on the URL that you'll advertise to all your users for OWA (e.g., webmail.xyz.com). You must map this URL to an IP address in your DNS as an A record. The ports on the firewall that you need to open are typically port 80 for HTTP and port 443 for HTTP over SSL (HTTPS).
I recommend that you use OWA with SSL for security. The sidebar "SSL's Benefits on OWA," page 9, describes SSL's advantages and offers tips for configuring OWA with SSL.
Method 1: Apply Redirection to IIS Default Documents
A simple way to redirect a URL is to apply the redirection directly to one of the default documents on the Default Web site's Properties Documents tab. You apply the redirection to the IIS default document (i.e., iisstart.asp for IIS 5.0 and default.htm for IIS 4.0). Applying the redirection directly is appropriate when the IIS server's primary role is to facilitate OWA and not to host any other Web application.
To use this method, open ISM, select theDefault Web site, right-click the default document and select Properties. Under When connecting to this resource, the content should come from in the dialog box that Figure 1 shows, select A redirection to a URL, and enter the URL (e.g., http://webmail.xyz.com) in the Redirect to text box. Select the A permanent redirection for this resource check box. Now, to access the OWA site, users need only enter webmail.xyz.com in their browser.
The main advantage of this approach is its simplicity and its convenience for administering and maintaining the Web site. The FQDN maps to the IP address of your IIS server, and the IIS server handles the redirection to the Exchange virtual directory. This configuration also doesn't adversely affect system upgrades and OWA patches because you haven't modified any of the default OWA directory paths.
The disadvantage of this method is that the root for the IIS server is no longer accessible through a Web browser. If the loss of Web administrative functionality is an acceptable compromise, this lack of access isn't necessarily bad because the default site as installed has components that can pose security risks. The most important of these risks is the IISSamples virtual directory. If you're setting up an IIS server, be sure to read the "Microsoft Internet Information Server 4.0 Security Checklist" (http://www.microsoft.com/technet/security/iischk.asp).