Knowledge Base

How to manage Outlook Web Access features in Exchange Server 2003

Article ID: 830827

Article Last Modified on 10/25/2007

APPLIES TO

Microsoft Exchange Server 2003 Enterprise Edition
Microsoft Exchange Server 2003 Standard Edition

Important This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows registry

INTRODUCTION

Several new features were introduced in Microsoft Office Outlook Web Access for Exchange Server 2003 including forms-based authentication, gzip compression, and attachment blocking. This article contains instructions for configuring various settings and features in Outlook Web Access 2003.

MORE INFORMATION

Enabling and disabling Outlook Web Access for internal clients only

Note If you are using Microsoft Exchange Server 2003 Service Pack 1 (SP1), the following steps do not apply. The Web DAV address check is not present in Microsoft Exchange 2003 Service Pack 1. To restrict access to Outlook Web Access if you are using Exchange Server 2003 SP1 or later, follow these steps:

In the Active Directory Users and Computers snap-in, right-click the user account that you want to restrict from using OWA, and then click Properties.
Click the Exchange Features tab, click Outlook Web Access, and then click Disable.

By default, user accounts that are mailbox-enabled are also enabled for Outlook Web Access in Exchange Server 2003.

You can enable users in your corporate network to access Outlook Web Access. At the same time, you can deny access to external clients. The key to this approach is a combination of a recipient policy and a special Hypertext Transfer Protocol (HTTP) virtual server. To use this approach, follow these steps:

Create a recipient policy with a Simple Mail Transfer Protocol (SMTP) domain name. Users who connect to an HTTP virtual server must have an e-mail address with the same SMTP domain as the virtual server. Creating a recipient policy is an efficient way to apply the same SMTP domain to multiple users.

Note Outlook Web Access users do not have to know the name of the SMTP domain.

Apply the recipient policy to the user accounts that you want to enable access for.
On the front-end server, create a new HTTP virtual server that specifies the domain that is used in the recipient policy.

After you have completed these steps, users whose e-mail addresses do not have the same SMTP domain as the HTTP virtual server cannot log on and access Outlook Web Access. Also, as long as you do not use the SMTP domain as the default domain, external users cannot determine what the SMTP domain is because the domain does not appear in the From field when users send e-mail messages outside the organization. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

293386 HTTP 401 or 404 error messages when you access OWA implicitly or explicitly

Besides enabling Outlook Web Access for users in your corporate network, you can also prevent specific internal users from accessing Outlook Web Access. You do this by disabling the HTTP and Network News Transfer Protocol (NNTP) protocols for those users.

To prevent an internal user from accessing Outlook Web Access, follow these steps:

In the Active Directory Users and Computers snap-in, open the user's Properties dialog box.
On the Exchange Features tab, click Outlook Web Access, and then click Disable.
Restart the IIS Admin Service.

Using browser language

When you use Microsoft Internet Explorer 5 or later to access Outlook Web Access, new installations of Exchange 2003 and upgrades to Exchange 2003 use the browser's language settings to determine the character set to use to encode information such as e-mail messages and meeting requests.

If you upgrade a Microsoft Exchange 2000 Server computer that was modified to use a browser's language setting, Exchange 2003 continues to function in the same manner. The following table lists the language groups and respective character sets.

Language group	Character set
Arabic	Windows 1256
Baltic	iso-8859-4
Chinese (Simplified)	Gb2131
Chinese Traditional	Big5
Cyrillic	koi8-r
Eastern European	iso-8859-2
Greek	iso-8859-7
Hebrew	windows-1255
Japanese	iso-2022-jp
Korean	ks_c_5601-1987
Thai	windows-874
Turkish	iso-8859-9
Vietnamese	windows-1258
Western European	iso-8859-1

If you expect Outlook Web Access users in your organization to send mail frequently, you can modify registry settings so that users who are running Internet Explorer 5 or later can use UTF-8 encoded UNICODE characters to send mail.

To modify the default language setting for Outlook Web Access, follow these steps.
Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

On the Exchange computer, log on by using the Exchange administrator account, and then start Registry Editor.
Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA

On the Edit menu, point to New, and then click DWORD Value.
Type UseRegionalCharset for the name of the DWORD, and then press ENTER.
Right-click the UseRegionalCharset DWORD value, and then click Modify.
In the Value data box, type 0, and then click OK.
Quit Registry Editor to save your changes.

Setting up a logon page

Enabling forms-based authentication (Cookie-auth) lets you 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 the browser, the cookie is cleared. Additionally, after a period of inactivity, the cookie is cleared automatically. To access e-mail, the new logon page requires the user to enter a domain, a user name, and a password, or a full user principal name (UPN) e-mail address and password. Forms-based authentication logon does not support Microsoft .NET Passport authentication with Outlook Web Access. This is a limitation of the Forms Based Authentication feature in Exchange 2003.

To enable this logon page, you must first enable forms-based authentication on the server and then secure the logon page by setting the cookie time-out period and adjusting the client-side security settings. For more information, see the “Enabling forms-based authentication” and “Setting the cookie authentication time-out” sections.

In Exchange 2003, forms-based authentication automatically sets the default domain for Basic Authentication on the Exchange virtual directory in Exchange System Manager to a backslash character (\). This restriction is designed to support user logons that use the UPN format. If you modify the default domain setting in Microsoft Internet Information Services (IIS) to anything other than the default domain setting of "\", Exchange System Manager resets the default domain setting to "\" on the server.

Additionally, if forms-based authentication is deployed in a front-end/back-end configuration, the default domain setting on the back-end server must match the default domain setting on the front-end server, or you may experience authentication problems. Because the front-end server requires "\" as the default domain, if forms-based authentication is enabled on the front-end server, the default domain on the back-end server must also be set to "\" in Exchange System Manager.

For more information about why you must modify the settings for the Exchange and Public virtual directories in Exchange System Manager, click the following article numbers to view the articles in the Microsoft Knowledge Base:

240105 General information on Directory Service/metabase synchronization in Exchange 2000 Server

264941 Changes to virtual directory settings are not maintained

To work around this issue, modify the Logon.asp page in Outlook Web Access to specify your domain or to include a list of domain names.

Note If you customize the Logon.asp page in Outlook Web Access, your changes may be overwritten if you later upgrade or re-install Exchange 2003. For more information about how to customize the Logon.asp page, click the following article number to view the article in the Microsoft Knowledge Base:

820378 Outlook Web Access session unexpectedly quits when forms-based authentication is used

Important Microsoft does not provide assistance in customizing Outlook Web Access objects, and if you contact Microsoft about an Outlook Web Access issue for a server that Outlook Web Access is customized on, you must replace the customized files with the original versions of the files. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

327178 Microsoft support policy for the customization of Outlook Web Access for Exchange

Enabling forms-based authentication

You must enable Secure Sockets Layer (SSL) on the server before you enable forms-based authentication. For more information about how to install a certificate in Microsoft Windows Server 2003 before you enable SSL, click the following article number to view the article in the Microsoft Knowledge Base:

816794 How to install imported certificates on a Web server in Windows Server 2003

To enable forms-based authentication in Exchange 2003, follow these steps.

Note In a front-end/back-end server environment, you must enable forms-based authentication only on the front-end server. Do not enable forms-based authentication on the back-end server. In an environment where you do not use a front-end server, enable forms-based authentication on the mailbox server.

Start Exchange System Manager.
If administrative groups are enabled, expand Administrative Groups.
Expand Servers, and then expand your front-end server.
Expand Protocols, expand HTTP, right-click Exchange Virtual Server, and then click Properties.
Click the Settings tab, and then click to select the Enable Forms Based Authentication check box.
In the Compression list, click the level of compression that you want.

Note We recommend that you do not enable compression in a single-server environment because compression in a single-server environment places an additional load on the server.

Click OK.
If you receive a message that states that the IIS service must be restarted, click OK. To restart IIS, type the following command at a command prompt: iisreset

If you enabled forms-based authentication on a front-end server, follow these steps on your back-end servers:

Start Exchange System Manager.
If administrative groups are enabled, expand Administrative Groups.
Expand Servers, and then expand your back-end server.
Expand Protocols, expand HTTP, and then expand Exchange Virtual Server.
Right-click the Exchange virtual directory that appears under the Exchange Virtual Server container, and then click Properties.
Click the Access tab, and then click Authentication.
If it is not already selected, click to select the Basic authentication check box.
Enter a backslash (\) in the Default Domain box.
Click OK two times to close the property windows.

Setting the cookie authentication time-out

For your Outlook Web Access logon page, you can give users two types of security options for authentication. Depending on their requirements, users can select either of these security options on the Outlook Web Access logon page:

Public or shared computer - Inform your users to select this option when they access Outlook Web Access from a computer that does not use the security settings for your organization. For example, an Internet kiosk computer does not use the security settings for your organization. The Public or shared computer option is the default option and provides a short default time-out option of 15 minutes.
Private computer - Inform your users to select this option when they are the sole operator of the computer and the computer uses the security settings for your organization. This option permits a much longer period of inactivity before automatically ending the session. Its internal default value is 24 hours. The Private computer option is intended to benefit Outlook Web Access users who use personal computers in their office or in their home.

Additionally, when Outlook Web Access clients log on by using forms-based authentication, they may also choose between the following two types of Outlook Web Access client versions:

Premium - This is the default version. It provides all Outlook Web Access features.

Note The Outlook Web Access premium client has special code so that typing in a message body is considered as activity.

Basic - This version provides faster performance but fewer features than the premium client. Use this version if you are on a slow connection.

In Exchange 2003, Outlook Web Access user credentials are stored in a cookie. When the user logs off from Outlook Web Access, the cookie is cleared and it is no longer valid for authentication. Additionally, by default, if your user is using a public computer and selects the Public or shared computer option on the Outlook Web Access logon screen, the cookie on this computer expires automatically after 15 minutes of user inactivity.

The automatic time-out is valuable because it helps protect a user's account from unauthorized access. However, although the automatic time-out greatly reduces the risk of unauthorized access, it does not completely eliminate the risk that an unauthorized user could access an Outlook Web Access account if a session is left running on a public computer. Therefore, make sure that you educate users about precautions to take to avoid risks.

To match the security requirements of the organization, an administrator can configure the inactivity time-out values on the Exchange front-end server. Exchange 2003 uses the following information to determine user activity:

Interaction between the client and the server is considered as activity. For example, if a user opens, sends, or saves an item, switches folders or modules, or refreshes the view or the Web browser window, this is considered as activity.
If a user enters text in Outlook Web Access items, it is not considered as activity. For example, if a user types in appointments, meeting requests, posts, contacts, tasks, or other items, this is not considered as activity.

To configure the time-out value, you must first enable forms-based authentication and then modify the registry settings on the server.

To set the Outlook Web Access forms-based authentication public computer cookie time-out value, follow these steps.
Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

On the Exchange front-end server, log on by using the Exchange administrator account, and then start Registry Editor.
Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA
On the Edit menu, point to New, and then click DWORD Value.
Type PublicClientTimeout for the name of the DWORD, and then press ENTER.
Right-click the PublicClientTimeout DWORD value, and then click Modify.
Under Base, click Decimal.
In the Value data box, type a value that represents the number of minutes for the time-out. This number must be between 1 and 43200. (43200 minutes are equal to 30 days.) If you do not set a value, a value of 15 is assumed.

Note The maximum possible value is 43200 for 30 days.
Click OK.

Important You must restart IIS for the changes to take effect. Also, if you set the TrustedClientTimeout value to a value that is lower than PublicClientTimeout, the TrustedClientTimeout value defaults to be equal to the PublicClientTimeout value. Likewise, if you set the PublicClientTimeout value to a value that is greater than the TrustedClientTimeout value, the TrustedClientTimeout value defaults to be equal to the PublicClientTimeout value.

To set the Outlook Web Access forms-based authentication trusted computer cookie time-out value:

On the Exchange front-end server, log on by using the Exchange administrator account, and then start Registry Editor.
Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA
On the Edit menu, point to New, and then click DWORD Value.
Type TrustedClientTimeout for the name of the DWORD, and then press ENTER.
Right-click the TrustedClientTimeout DWORD value, and then click Modify.
Under Base, click Decimal.
In the Value data box, type a value that represents the number of minutes for the time-out. This number must be between 1 and 43200. (43200 minutes are equal to 30 days.) If you do not set a value, a value of 1440 is assumed.

Note The maximum possible value is 43200 for 30 days.
Click OK.
Open a command prompt, type net stop w3svc, and then press ENTER.
After the services stop, type net start w3svc, and then press ENTER.

Enabling Outlook Web Access (gzip) compression

When you enable forms-based authentication in Exchange 2003, you can also enable gzip compression for static and dynamic files in Exchange 2003 virtual directories and virtual servers. By using compression, users can experience performance increases of up to 50 percent when they use slower network connections such as traditional dial-up access.

Depending on the compression setting that you use, Outlook Web Access compression works by compressing static or dynamic Web pages.

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

To use data compression for Outlook Web Access in Exchange 2003, the following prerequisites must be met:

Client

The client system must be running Microsoft Windows 2000 or later and must use one of the following Web browsers:

Internet Explorer 6 with the 328970 cumulative update or later. For more information about the 328970 cumulative update, click the following article number to view the article in the Microsoft Knowledge Base:

328970 MS02-066: November, 2002, cumulative patch for Internet Explorer
Netscape Navigator 6.0 or later.

Server

Forms-based authentication must be enabled.

When you enable gzip compression in your Exchange environment, you must account for the type of deployment scenario. The recommended approach is to deploy dedicated front-end servers. In this kind of scenario, the following requirements apply:

The front-end Exchange 2003 computer must be running under Windows Server 2003.
The back-end Exchange 2003 computers may be running under either Windows 2000 or Windows Server 2003.

Another type of deployment scenario involves not deploying dedicated front-end Exchange computers (also known as a back-end only deployment). In this situation, the Exchange 2003 computer must be running under Windows Server 2003.

Note If you use Exchange 2003 front-end servers to access Exchange 2000 back-end servers, disable Outlook Web Access compression support on the front-end servers until all back-end servers are upgraded to Exchange 2003.

Together with the previous prerequisites, you may also have to enable HTTP 1.1 support through proxy servers for some dial-up connections. (HTTP 1.1 support is required for compression to function correctly.)

To enable data compression, follow these steps:

Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
Expand Servers, expand ServerName, expand Protocols, and then expand HTTP.
Right-click Exchange Virtual Server, and then click Properties.
Click the Settings tab.
Click to select the Enable Forms Based Authentication check box.
To configure compression, click the compression level that you want to use in the Compression box, and then click OK.
Click OK.
Restart the following services:
- Microsoft Exchange System Attendant service
- IIS Admin Service
Note You must configure SSL in IIS before you can enable forms-based authentication on the server.

Blocking Web beacons

In Exchange 2003, Outlook Web Access makes it more difficult for people who send junk e-mail messages to use beacons to retrieve e-mail addresses. Beacons frequently come in the form of images that are downloaded onto a user's computer when the user opens a junk e-mail item. After the images download, a beacon notification is sent to the sender of the junk e-mail informing the sender that the e-mail address of your user is valid. The result is that the user receives junk e-mail more frequently because the junk e-mail sender now knows that the e-mail address is valid.

In Outlook Web Access, an incoming message with any content that could be used as a beacon, regardless of whether the message actually contains a beacon, prompts Outlook Web Access to display the following warning message:

To help protect your privacy, links to images, sounds, or other external content in this message have been blocked. Click here to unblock content.

If users know that a message is legitimate, they can click the Click here to unblock content link in the warning message to unblock the content. If your users do not recognize the sender or the message, they can open the message without unblocking the content and then delete the message without triggering beacons. If your organization does not want to use this feature, you can disable the blocking option for Outlook Web Access.

To disable the blocking option, follow these steps:

Use a Web browser to gain access to Outlook Web Access.
Click Options.
Under Privacy and Junk E-mail Prevention, click to clear the Block external content in HTML e-mail messages check box.

Blocking attachments

With Outlook Web Access, you can block users from opening, sending, or receiving specified attachment types. In particular, you can do the following:

Prevent users from accessing certain file type attachments. By default, all new Exchange 2003 installations block attachments of Levels 1 and 2 file types and Levels 1 and 2 MIME types. This feature is particularly useful in stopping Outlook Web Access users from opening attachments at public Internet terminals. Opening attachments at public Internet terminals could potentially compromise corporate security. If an attachment is blocked, a warning message indicating that the user cannot open the attachment appears in the InfoBar of the e-mail message. Outlook Web Access users who are working in their offices or who are connected to the corporate network from home can open and read attachments. You can enable full intranet access to attachments by providing the URL to the back-end servers and permitting attachments on the Exchange back-end servers.
Prevent users from sending or receiving attachments with specific file name extensions that could contain viruses. This feature in Outlook Web Access matches the attachment blocking functionality in Outlook. For received messages, a warning message indicating that an attachment is blocked appears in the InfoBar of the e-mail message. For sent messages, users cannot upload any files with extensions that appear on the block list.

To change the attachment blocking settings, you must modify the registry settings on the server.

Note In a front-end / back-end configuration, the registry modifications should be made on the back-end server.

To do this, follow these steps.

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

On the Exchange computer, log on by using the Exchange administrator account, and then start Registry Editor.
Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA
On the Edit menu, point to New, and then click DWORD Value.
Type DisableAttachments for the name of the DWORD value, and then press ENTER.
Right-click the DisableAttachments DWORD value, and then click Modify.
Under Base, click Decimal.
In the Value data box, type one of the following numbers:
- To permit all attachments, type 0.
- To permit no attachments, type 1.
- To permit attachments from back-end servers only, type 2.
Click OK.
Open a command prompt, type net stop w3svc, and then press ENTER.
After the services stop, type net start w3svc, and then press ENTER.

Additional query words: XCCC FBA FE

Keywords: kbpubtypekc kbinfo kbhowto KB830827

Microsoft KB Archive/830827

Contents