Configuring Exchange 2003 for Client Access

Collapse All

Topic Last Modified: 2006-12-06

This topic provides information about configuring Microsoft® Exchange Server 2003 for client access. Specifically, this topic covers:

Securing your Exchange messaging environment.
Deploying your server architecture.
Configuring the Exchange servers for your supported client access methods.

Permissions for Configuring Exchange 2003 for Client Access

Table 1 lists the required permissions or roles for the procedures referenced in this topic.

Table 1 Procedures referenced in this topic and corresponding permissions

Procedure	Required permissions or roles
Set up Secure Sockets Layer (SSL) on a server	Local Administrator
Obtain a server certificate from a certification authority	Local Administrator
Add Certificate Manager to Microsoft Management Console (MMC)	Local Administrator
Back up your server certificate	Local Administrator
Require SSL	Local Administrator
Designate a front-end server	Local Administrator
Configure your Exchange front-end server to use remote procedure call (RPC) over HTTP	Local Administrator
Configure the RPC virtual directory	Local Administrator Domain Administrator
Configure the RPC Proxy server to use the specified default ports for RPC over HTTP inside the corporate network	Local Administrator Domain Administrator
Configure the global catalog servers to use the specified default ports for RPC over HTTP inside the perimeter network	Local Administrator Domain Administrator
Create a Microsoft Office Outlook® profile to use with RPC over HTTP	No specific permissions necessary
Configure Exchange 2003 to use Microsoft Exchange ActiveSync®	Local Administrator
Configure Pocket PC Phone Edition devices to use Exchange ActiveSync	No specific permissions necessary
Verify ACE/Agent is configured to protect the entire Web server	Local Administrator
Limit SecurID Authentication to the Microsoft-Exchange-ActiveSync virtual directory	Local Administrator
Configure custom HTTP responses for devices	Local Administrator
Enable Microsoft Outlook Mobile Access	Local Administrator
Configure Pocket PC Phone Edition devices to use Outlook Mobile Access	No specific permissions required
Enable forms-based authentication	Local Administrator Exchange Administrator
Enable data compression	Local Administrator Exchange Administrator
Start, pause, or stop the virtual server	Local Administrator Exchange Administrator

Securing Your Exchange Messaging Environment

Securing your Exchange messaging environment involves the following deployment activities.

Update your server software.
Secure the messaging environment.
Secure communications.

To secure your messaging system, complete these steps in the order given.

Updating Your Server Software

After you install Exchange Server 2003, you should update the server software on your Exchange servers and any other server that Exchange communicates with, such as your global catalog servers and domain controllers. For more information about updating your software with the latest security patches, see the Exchange Server Security Center Web site (http://go.microsoft.com/fwlink/?LinkId=18412).

For more information about Microsoft security, see the Microsoft Security Web site (http://go.microsoft.com/fwlink/?linkid=21633).

Securing the Exchange Messaging Environment

As a best practice alternative to locating your front-end Exchange 2003 servers in the perimeter network, deploy Microsoft Internet Security and Acceleration (ISA) Server 2000. ISA Server act as advanced firewalls that control Internet traffic entering your network. When you use this configuration, you put all of your Exchange 2003 servers within your corporate network, and use ISA Server as the advanced firewall server exposed to Internet traffic in your perimeter network.

All inbound Internet traffic bound to your Exchange servers (such as Microsoft Office Outlook Web Access, RPC over HTTP communication from Outlook 2003 clients, Outlook Mobile Access, Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4rev1 (IMAP4), and so on) is processed by the ISA Server. When ISA Server receives a request to an Exchange server, ISA Server proxies the requests to the appropriate Exchange servers on your internal network. The internal Exchange servers return the requested data to the ISA Server, and then ISA Server sends the information to the client through the Internet. Figure 1 shows an example of a recommended ISA Server deployment.

Figure 1 Deploying Exchange 2003 behind ISA Server
ISA Server on Perimeter Network

Securing Communications

To secure communication for your Exchange messaging environment, you need to perform the following tasks:

Secure the communications between the client messaging applications and the Exchange front-end server.
Secure the communications between the Exchange front-end server and the internal network.

The following sections include information about securing communication for these two situations.

Securing Communications Between the Client and Exchange Front-End Server

To secure data transmitted between the client and the front-end server, it is highly recommended that you enable the front-end server to use Secure Sockets Layer (SSL). In addition, to ensure that user data is always secure, you should disable access to the front-end server without SSL (this option can be set in the SSL configuration). When using basic authentication, it is critical to protect the network traffic by using SSL to protect user passwords from network packet sniffing.

Note:
If you do not use SSL between clients and the front-end server, HTTP data transmission to your front-end server will not be secure. It is highly recommended that you configure the front-end server to require SSL.

It is recommended that you obtain an SSL certificate by purchasing a certificate from a third-party certification authority (CA). Purchasing a certificate from a certification authority is the preferred method because the majority of browsers trust many of these certification authorities.

As an alternative, you can use Certificate Services to install your own certification authorities. Although installing your own certification authority may be less expensive, browsers will not trust your certificate, and users will receive a warning message indicating that the certificate is not trusted. For more information about SSL, see Microsoft Knowledge Base article 320291, "XCCC: Turning On SSL for Exchange 2000 Server Outlook Web Access" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320291).

Using Secure Sockets Layer

To protect outbound and inbound mail, deploy SSL to encrypt messaging traffic. You can configure SSL security features on an Exchange server to verify the integrity of your content, verify the identity of users, and encrypt network transmissions. Exchange, just like any Web server, requires a valid server certificate to establish SSL communications. You can use the Web Server Certificate Wizard to either generate a certificate request file (NewKeyRq.txt, by default) that you can send to a certification authority, or to generate a request for an online certification authority, such as Certificate Services.

If you are not using Certificate Services to issue your own server certificates, a third-party certification authority must approve your request and issue your server certificate. For more information about server certificates, see "Obtaining and Installing Server Certificates" later in this topic. Depending on the level of identification assurance offered by your server certificate, you can expect to wait several days to several months for the certification authority to approve your request and send you a certificate file. You can have only one server certificate for each Web site.

After you receive a server certificate file, use the Web Server Certificate Wizard to install it. The installation process attaches (or binds) your certificate to a Web site.

For detailed steps, see How to Set Up SSL on a Server.

Important:
You must be a member of the Administrators group on the local computer to perform the above procedure, or you must have been delegated the appropriate authority. As a security best practice, log on to your computer using an account that is not in the Administrators group, and then use the Run as command to run IIS Manager as an administrator. From the command prompt, type the following command: `runas /user:administrative_accountname "mmc%systemroot%\system32\inetsrv\iis.msc"`

Important:

You must be a member of the Administrators group on the local computer to perform the above procedure, or you must have been delegated the appropriate authority. As a security best practice, log on to your computer using an account that is not in the Administrators group, and then use the Run as command to run IIS Manager as an administrator. From the command prompt, type the following command: runas /user:administrative_accountname "mmc%systemroot%\system32\inetsrv\iis.msc"

If you require 128-bit key encryption, your users must use Web browsers that support 128-bit encryption. For information about upgrading to 128-bit encryption capability, see the Microsoft Product Support Services Web site (http://go.microsoft.com/fwlink/?linkid=14898).

Obtaining and Installing Server Certificates

You can obtain server certificates from an outside certification authority (CA), or you can issue your own server certificates using Certificate Services. After you obtain a server certificate, you can install it. When you use the Web Server Certificate Wizard to obtain and install a server certificate, the process is referred to as creating and assigning a server certificate.

For detailed steps, see How to Obtain a Server Certificate from a Certification Authority.

This section explains the issues to consider when deciding whether to obtain your server certificates from an outside CA, or to issue your own server certificates. This section includes the following information:

Obtaining server certificates from a certification authority
Issuing your own server certificates
Installing server certificates
Backing up server certificates

Obtaining Server Certificates from a Certification Authority

If you are replacing your current server certificate, IIS continues to use that certificate until the new request has been completed. When you are choosing a CA, consider the following questions:

Will the CA be able to issue a certificate that is compatible with all of the browsers used to access my server?
Is the CA a recognized and trusted organization?
How will the CA provide verification of my identity?
Does the CA have a system for receiving online certificate requests, such as requests generated by the Web Server Certificate Wizard?
How much will the certificate cost initially, and how much will renewal or other services cost?
Is the CA familiar with my organization or my company's business interests?

Note:
Some certification authorities require you to prove your identity before they will process your request or issue a certificate.

Issuing Your Own Server Certificates

When deciding whether to issue your own server certificates, consider the following:

Understand that Certificate Services accommodates different certificate formats and provides for auditing and logging of certificate-related activity.
Compare the cost of issuing your own certificates against the cost of buying a certificate from a certification authority.
Remember that your organization will require an initial adjustment period to learn, implement, and integrate Certificate Services with existing security systems and policies.
Assess the willingness of your connecting clients to trust your organization as a certificate supplier.

Use Certificate Services to create a customizable service for issuing and managing certificates. You can create server certificates for the Internet or for corporate intranets, giving your organization complete control over certificate management policies. For more information, see Certificate Services in Windows Server™ 2003 Help.

Online requests for server certificates can only be made to local and remote Enterprise Certificate Services and remote stand-alone Certificate Services. The Web Server Certificate Wizard does not recognize a stand-alone installation of Certificate Services on the same computer when requesting a certificate. If you need to use Web Server Certificate Wizard on the same computer as a stand-alone Certificate Services installation, use the offline certificate request to save the request to a file and then process it as an offline request. For more information, see Certificate Services in Windows Server 2003 Help.

Note:
If you open a Server Gated Cryptography (SGC) certificate, you may receive the following notice on the General tab: The certificate has failed to verify for all of its intended purposes. This notice is issued because of the way SGC certificates interact with Microsoft Windows® and does not necessarily indicate that the certificate does not work properly.

Installing Server Certificates

After obtaining a server certificate from a CA, or after issuing your own server certificate using Certificate Services, use the Web Server Certificate Wizard to install it.

Backing Up Server Certificates

You can use the Web Server Certificate Wizard to back up server certificates. Because IIS works closely with Windows, you can use Certificate Manager, which is called Certificates in Microsoft Management Console (MMC), to export and back up your server certificates.

For detailed steps about how to add Certificate Manager to an empty MMC, see How to Add Certificate Manager to Microsoft Management Console.

After you install Certificate Manager, you can back up your certificate. For detailed steps, see How to Back Up Your Server Certificate.

After you configure your network to issue server certificates, you need to secure your Exchange front-end server and the services for your Exchange server by requiring SSL communication to the Exchange front-end server. The following section describes how to enable SSL for your default Web site.

Enabling SSL for the Default Web Site

After you obtain an SSL certificate to use either with your Exchange front-end server on the default Web site or on the site where you host the \RPC, \OMA, \Microsoft-Server-ActiveSync, \Exchange, \Exchweb, and \Public virtual directories, you can enable the default Web site to require SSL.

For detailed steps, see How to Configure Virtual Directories to Use SSL.

Note:
The \Exchange, \Exchweb, \Public, \OMA, and \Microsoft-Server-ActiveSync virtual directories are installed by default on any Exchange 2003 installation. The \RPC virtual directory for RPC over HTTP communication is installed manually when you configure Exchange to support RPC over HTTP. For information about how to set up Exchange to use RPC over HTTP, see Exchange Server 2003 RPC over HTTP Deployment Scenarios (http://go.microsoft.com/fwlink/?LinkId=47577).

Note:

The \Exchange, \Exchweb, \Public, \OMA, and \Microsoft-Server-ActiveSync virtual directories are installed by default on any Exchange 2003 installation. The \RPC virtual directory for RPC over HTTP communication is installed manually when you configure Exchange to support RPC over HTTP. For information about how to set up Exchange to use RPC over HTTP, see Exchange Server 2003 RPC over HTTP Deployment Scenarios (http://go.microsoft.com/fwlink/?LinkId=47577).

After you complete this procedure, all virtual directories on the Exchange front-end server on the default Web site are configured to use SSL.

Securing Communications Between Exchange Front-End Server and Other Servers

After you secure your communications between the client computers and the Exchange front-end servers, you must secure the communications between the Exchange front-end server and back-end servers in your organization. HTTP, POP, and IMAP communications between the front-end server and any server with which the front-end server communicates (such as back-end servers, domain controllers, and global catalog servers) is not encrypted. When the front-end and back-end servers are in a trusted physical or switched network, this lack of encryption is not a concern. However, if front-end and back-end servers are kept in separate subnets, network traffic may pass over unsecured areas of the network. The security risk increases when there is greater physical distance between the front-end and back-end servers. In this case, it is recommended that this traffic be encrypted to protect passwords and data.

Using IPSec to Encrypt IP Traffic

Windows 2000 supports Internet Protocol security (IPSec), which is an Internet standard that allows a server to encrypt any IP traffic, except traffic that uses broadcast or multicast IP addresses. Generally, you use IPSec to encrypt HTTP traffic; however, you can also use IPSec to encrypt Lightweight Directory Access Protocol (LDAP), RPC, POP, and IMAP traffic. With IPSec you can:

Configure two servers running Windows 2000 to require trusted network access.
Transfer data that is protected from modification (using a cryptographic checksum on every packet).
Encrypt any traffic between the two servers at the IP layer.

In a front-end and back-end topology, you can use IPSec to encrypt traffic between the front-end and back-end servers that would otherwise not be encrypted. For more information about configuring IPSec with firewalls, see Microsoft Knowledge Base article 233256, "How to Enable IPSec Traffic Through a Firewall" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=233256).

Deploying the Exchange Server Architecture

After you secure your Exchange messaging environment, you can deploy the Exchange front-end and back-end server architecture. For more information about the Exchange front-end and back-end server architecture, see "Protocols" in the guide Planning an Exchange Server 2003 Messaging System (http://go.microsoft.com/fwlink/?linkid=47584).

To configuring the Exchange front-end and back-end server architecture, you need to configure one Exchange server as a front-end server. Before you continue with the installation process, it is important to review your deployment options. The following section helps you decide if you want to deploy Exchange 2003 in a front-end and back-end server configuration.

A front-end and back-end configuration is recommended for multiple-server organizations that use Outlook Web Access, POP, or IMAP and for organizations that want to provide HTTP, POP, or IMAP access to their employees.

Configuring a Front-End Server

A front-end server is an ordinary Exchange server until it is configured as a front-end server. A front-end server must not host any users or public folders and must be a member of the same Exchange 2003 organization as the back-end servers (therefore, a member of the same Windows 2000 Server or Windows Server 2003 forest). Servers running either Exchange Server 2003 Enterprise Edition or Exchange Server 2003 Standard Edition can be configured as front-end servers.

For detailed steps, see "How to Designate a Front-End Server" in the Exchange Server 2003 and Exchange 2000 Server Front-End and Back-End Server Topology Guide (http://go.microsoft.com/fwlink/?LinkId=47567).

To begin using your server as a front-end server, restart the server. For more information about front-end and back-end scenarios, configurations, and installation, see the following guides:

Planning an Exchange Server 2003 Messaging System (http://go.microsoft.com/fwlink/?linkid=47584)
Using Microsoft Exchange 2000 Front-End Servers (http://go.microsoft.com/fwlink/?linkid=14575)

Configuring Exchange for Client Access

Configuring Exchange for client access involves configuring Exchange to handle the protocols and clients that you want to support. The following section describes how to enable the client protocols supported by Exchange on the Exchange server. This section includes the following information:

Configuring mobile device support
Configuring Outlook Web Access
Enabling POP3 and IMAP4 Virtual Servers

For information about configuring RPC over HTTP for Outlook 2003, see Exchange Server 2003 RPC over HTTP Deployment Scenarios (http://go.microsoft.com/fwlink/?LinkId=47577).

Configuring Mobile Device Support

Configuring mobile device support for Exchange 2003 involves the following activities:

Configure synchronization.
Configure Exchange ActiveSync to use RSA SecurID.
Enable Outlook Mobile Access.

Configuring Synchronization

When you install Exchange, synchronization access to Exchange is enabled by default for all users in your organization. You can also use the Active Directory Users and Computers snap-in to enable individual users for synchronization access.

Configuring Exchange ActiveSync

Exchange ActiveSync can be enabled and disabled at Exchange organization level and at the user level.

For details about how to enable and disable Exchange ActivceSync at the organization level, see How to Enable and Disable Exchange ActiveSync Features at the Organizational Level.

For details about how to enable and disable Exchange ActiveSync for individual users, see How to Enable and Disable Exchange ActiveSync Features at the User Level.

After you have enabled Exchange ActiveSync you can configure a mobile device such as a Pocket PC Phone Edition device to use Exchange ActiveSync. Perform this procedure on each mobile device in your organization. As an alternative, you can instruct your users how to configure their own devices.

For detailed steps, see How to Configure a Mobile Device to Use Exchange ActiveSync.

Up-to-Date Notifications

Microsoft Windows Mobile™ 2003 devices are able to receive notifications generated by Exchange 2003 that initiate Exchange ActiveSync synchronization between a user's device and his or her Exchange mailbox. This synchronization allows the users mobile device to be up-to-date with the latest Exchange information. For detailed steps, see How to Specify a Mobile Operator for Up-to-Date Notifications on a Device.

Configuring Exchange ActiveSync to Use RSA SecurID

As an added level of security, you can use Microsoft Windows Mobile devices with Exchange ActiveSync in conjunction with RSA SecurID two-factor authentication.

Note:
No additional device configuration is required to support RSA SecurID. The device presents the appropriate authentication automatically when synchronizing with an Exchange ActiveSync server protected by RSA SecurID.

Using RSA SecurID with Exchange ActiveSync involves the following steps.

Set up the RSA SecurID server components.
Configure Internet Information Server (IIS) to use RSA SecurID.
Set up user accounts.
Configure ISA Server 2000.

Setting Up the RSA SecurID Server Components

To configure the RSA SecurID server components, you need to:

Set up the RSA ACE/Server The RSA ACE/Server is the RSA server that stores and manages authentication tickets and credentials for your users. To set up the RSA ACE/Server, follow the procedures as outlined in the RSA SecurID documentation provided by RSA Security Inc.
Set up the RSA ACE/Agent on the front-end server The RSA ACE/Agent is the Internet Server Application Programming Interface (ISAPI) filter that performs authentication and communicates to the ACE/Server to retrieve SecurID credentials. To set up the RSA ACE/Agent, follow the procedures as outlined in the RSA documentation.

Configuring IIS to Use RSA SecurID

Configuring IIS for RSA and Exchange ActiveSync involves the following procedures.

Protect the Exchange ActiveSync virtual directories.
Customize the custom HTTP response headers.
Install SecurID screens (optional). For information about installing these screens, see the RSA SecurID documentation.

Complete these steps to properly configure IIS for SecurID and Exchange ActiveSync operations.

Protecting the Exchange ActiveSync Virtual Directories

The first step to configuring IIS is to protect the virtual directories that your users access when they use Exchange ActiveSync. Exchange Server 2003 uses the \Microsoft-Server-ActiveSync virtual directory.

You can protect this virtual directory in one of the following two ways:

Protect the entire Web server (recommended) In this option, you protect all virtual roots on the IIS server with RSA ACE/Agent, including any other services implemented by the front-end server. For example, you may have configured your front-end Exchange server as an access point for Outlook Mobile Access or for Outlook Web Access. By default, the ACE/Agent is configured to protect the entire Web server. For detailed steps about how to verify this, see How to Verify ACE/Agent is Configured to Protect the Entire Web Server.
Protect only the Exchange ActiveSync virtual directories In this option, you configure the RSA ACE/Agent so that only Exchange ActiveSync is protected by SecurID. Use this option if you intend to enable additional services, such as Outlook Web Access and Outlook Mobile Access, on the same server without protecting those services with SecurID. For detailed steps, see How to Limit SecurID Authentication to the Microsoft-Exchange-ActiveSync Virtual Directory.

Customizing the HTTP Response Header for Devices

The ActiveSync client on the Microsoft Windows Mobile device must be able to distinguish between RSA SecurID authentication and Exchange ActiveSync responses. To enable this capability, you need to configure custom HTTP response headers on the WebID virtual root that contains the HTML forms configured by RSA ACE/Agent.

For detailed steps, see How to Configure Custom HTTP Responses for Devices.

Setting Up User Accounts

User accounts for SecurID should be set up by the Administrator as recommended by the RSA SecurID product documentation, with the following restriction:

For all users, SecurID user IDs must be selected to match the Windows account name. Exchange ActiveSync with SecurID does not function for users who have a distinct RSA user ID that does not match their Windows account name.

Configuring ISA Server 2000

ISA Server 2000 Feature Pack 1 and RSA SecurID technology are integrated on the ISA Server. Currently, using RSA SecurID with ISA Server 2000 with Feature Pack 1 is unsupported. You can, however, deploy RSA SecurID with ISA Server 2000 Feature Pack 1, but you must configure the ISA Server to enable pass-through authentication. In this scenario, RSA authentication still occurs at the front-end server, not at the ISA Server. For information about how to enable pass-through authentication, see the ISA Server 2000 documentation.

Enabling Outlook Mobile Access

By default, all users are enabled for Exchange ActiveSync and Outlook Mobile Access. However, only Exchange ActiveSync is enabled on the Exchange server; by default, Outlook Mobile Access is disabled. This section describes how to enable Outlook Mobile Access on your Exchange server.

Perform the following steps to enable your Exchange 2003 users to use Outlook Mobile Access.

Configure your Exchange 2003 front-end server for Outlook Mobile Access.
Enable Outlook Mobile Access on the Exchange server.
Configure user devices to use a mobile connection.
Instruct your users in using Outlook Mobile Access.

Step 1: Configuring Your Exchange 2003 Front-End Server for Outlook Mobile Access

By default, the Outlook Mobile Access virtual directory (which allows your users to access Exchange from a mobile device) is installed with Exchange 2003. This virtual directory has the same capabilities and configuration settings as the Outlook Web Access virtual directory. When you configure a server to use Outlook Mobile Access, you should configure the server in the same way you configure a server for Outlook Web Access. For information about how to configure your Exchange 2003 servers to use Outlook Web Access, see the guide Using Microsoft Exchange 2000 Front-End Servers (http://go.microsoft.com/fwlink/?linkid=14575).

Step 2: Enabling Outlook Mobile Access on the Exchange Server

After you configure your front-end server to use Outlook Mobile Access, you need to enable Outlook Mobile Access on your Exchange servers. Outlook Mobile Access can be enabled at the organizational level and at the individual user level.

For detailed steps about how to enable Outlook Mobile Access at the organizational level, see How to Enable or Disable Outlook Mobile Access at the Organizational Level.

After you enable Outlook Mobile Access, you can modify the Outlook Mobile Access settings for users or groups of users using the Active Directory Users and Computers snap-in. For detailed steps about how to enable Outlook Mobile Access at the user level, see How to Enable or Disable Outlook Mobile Access at the User Level.

Step 3: Configuring Users' Devices to Use a Mobile Connection

To access Exchange 2003 using Outlook Mobile Access, users must have a mobile device from a mobile operator who has an established data network for mobile data. Before your users connect to Exchange 2003 and use Outlook Mobile Access or Exchange ActiveSync over a mobile connection, instruct them about how to configure their devices to use a mobile network, or provide them with resources that explain how to do so. For more information about how to configure mobile devices and Exchange ActiveSync, see How to Configure a Mobile Device to Use Exchange ActiveSync.

Step 4: Instructing Your Users in Using Outlook Mobile Access

After you configure Exchange 2003 for Outlook Mobile Access, and your users have mobile devices that can use a mobile network to access Exchange 2003 servers, they need to know how to access their Exchange server and use Outlook Mobile Access. For detailed steps about how to configure a Pocket PC-based mobile device to use Outlook Mobile Access, see How to Access Exchange Data Using Outlook Mobile Access.

Configuring Outlook Web Access

By default, Outlook Web Access is enabled for all of your users after you install Exchange 2003. However, you can enable the following features for Outlook Web Access:

Forms-based authentication
Outlook Web Access compression

Forms-Based Authentication

You can enable a new logon page for Outlook Web Access that stores the user's name and password in a cookie instead of in the browser. When a user closes his or her browser, the cookie is cleared. Additionally, after a period of inactivity, the cookie is cleared automatically. The new logon page requires users to enter either their domain, user name (in the format domain\username), and password, or their full user principal name (UPN) e-mail address and password to access their e-mail.

To enable the Outlook Web Access logon page, you must enable forms-based authentication on the server. For detailed steps, see How to Enable Forms-Based Authentication.

Outlook Web Access Compression

Outlook Web Access supports data compression, which is optimal for slow network connections. Depending on the compression setting you use, Outlook Web Access compresses static and/or dynamic Web pages. For detailed steps, see How to Enable Outlook Web Access Data Compression.

Table 4 lists the compression settings that are available in Exchange Server 2003 for Outlook Web Access.

Table 4 Available compression settings for Outlook Web Access

Compression setting	Description
High	Compresses both static and dynamic pages.
Low	Compresses only static pages.
None	No compression is used.

When you use data compression, your users can see performance increases of as much as 50 percent on slower network connections, such as traditional dial-up access.

Requirements for Outlook Web Access Compression

To use data compression for Outlook Web Access in Exchange Server 2003, you must verify that you have the following prerequisites:

The Exchange server that users authenticate against for Outlook Web Access must be running Windows Server 2003.
Your users' mailboxes must be on Exchange 2003 servers. (If you have a mixed deployment of Exchange mailboxes, you can create a separate virtual server on your Exchange server just for Exchange 2003 users and enable compression on it.)
Client computers must be running Internet Explorer version 6 or later. The computers must also be running Windows XP or Windows 2000 and have installed on them the security update that is discussed in Microsoft Security Bulletin MS02-066, "Cumulative Patch for Internet Explorer (Q328970)" (http://go.microsoft.com/fwlink/?LinkId=16694).

Note:
If a user does not have a supported browser for compression, the client still behaves normally.
You may need to enable HTTP 1.1 support through proxy servers for some dial-up connections. (HTTP 1.1 support is required for compression to function properly.)

Note:
If a user does not have a supported browser for compression, the client still behaves normally.

Enabling POP3 and IMAP4 Virtual Servers

By default, the POP3 and IMAP4 virtual servers are disabled on a new installation of Exchange Server 2003. To enable the POP3 and IMAP4 virtual servers, you must first use the Services snap-in to MMC and set the services to start automatically. If you set the services to start automatically and then need to start, pause, or stop the services, use Exchange System Manager. For detailed steps, see How to Start, Pause, or Stop a Virtual Server.

Note:
For information about enabling IMAP4 and POP3 and adding those resources to an Exchange cluster, see "Managing Exchange Clusters," in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=47617).