Exchange 2003 tuning parameters -- Outlook Web Access

Learn how to secure Outlook Web Access with attachment blocking, freedocs, cookie timeout specifications, & feature segmentation; and discover how to enable public folder replies.

Now that we have gone over the legacy tuning parameters from Exchange 2000 that need to be removed, let's dive...

into the new tuning parameters in Exchange 2003. Some of these parameters (e.g., the BOOT.INI switches, the OWA spell-check throttling, and so on) have been mentioned in previous chapters, so those won't be duplicated here. I have listed the Exchange 2003 tuning parameters in the following subsections.

OWA attachment blocking

You are reading tip #3 from "7 tips in 7 minutes: Exchange Server 2003 tips and tricks," excerpted from Chapter 10 of the book "Microsoft Exchange Server 2003 Distilled," by Scott Schnoll, copyright 2004, published by Addison-Wesley Professional.
OWA is highly configurable. We've discussed in earlier chapters some features (such as themes and spell-check management) that demonstrate this. You can also configure or enable other settings that provide even more control over the OWA experience, such as attachment blocking, access to freedocs, control over the OWA cookie timeout, enhanced segmentation, and more.

As part of Microsoft's Trustworthy Computing initiative, Exchange 2003 OWA automatically blocks attachments with certain extensions. OWA prevents the sending and opening of a superset of attachments and MIME types using a two-level blocking mechanism. Level 1 items are totally blocked. Level 2 items can be accessed, but only if first saved locally. The list of blocked Level 1 and Level 2 file extensions and blocked MIME types are configured through four registry entries, which are listed in the following registry entries showing their default values. As you can see, many of the default Level 1 entries for file extensions and MIME types are also default Level 2 entries. When the same entry is present for both levels, Level 1 takes precedence, and the attachment is blocked. You are free to edit any of these entries to suit your organization's specific needs. If you reinstall or update Exchange, your changes will remain.

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: Level1FileTypes
Type: REG_SZ
Value Data:
ade,adp,app,asx,bas,bat,chm,cmd,com,cpl,crt,csh,exe,fxp,hlp,hta, inf,ins,isp,js,jse,ksh,lnk,mda,mdb,mde,mdt,mdw,mdz,msc,msi,msp, mst,ops,pcd,pif,prf,prg,reg,scf,scr,sct,shb,shs,url,vb,vbe,vbs, wsc,wsf,wsh

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: Level1MIMETypes
Type: REG_SZ
Value Data: application/hta,x-internet-signup,application/javascript,application/x-javascript, text/javascript,application/msaccess,application/prg, text/scriptlet

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: Level2FileTypes
Type: REG_SZ
Value Data:
ade,adp,asx,bas,bat,chm,cmd,com,cpl,crt,exe,hlp,hta,htm,html,htc, inf,ins,isp,js,jse,lnk,mda,mdb,mde,mdz,mht,mhtml,msc,msi,msp,mst, pcd,pif,prf,reg,scf,scr,sct,shb,shs,shtm,shtml,stm,url,vb,vbe,vbs, wsc,wsf,wsh,xml,dir,dcr,plg,spl,swf

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: Level2MIMETypes
Type: REG_SZ
Value Data: text/xml,application/xml,application/hta,text/html, application/octet-stream,application/x-shockwave-flash, application/futuresplash,application/x-director

In addition to this level of attachment blocking, OWA 2003 enables you to selectively block attachments for users based on how they are accessing OWA. For example, for security, bandwidth, or other reasons, you might wish to block attachments for users who access OWA from the Internet (e.g., via a front-end server) while allowing full access to attachments for users accessing OWA from your private network (e.g., directly via the back-end server). To do this, you need to add the following new entry to the registry(ies) of your OWA server(s).

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: DisableAttachments
Value Data: 0, 1, or 2 (dec)

If DisableAttachments is not present or is set to 0, the standard Level 1/Level 2 attachment blocking is performed. When Disable Attachments is set to 1, all attachments are blocked. If you set DisableAttachments to 2, attachments not blocked by Level 1/Level 2 blocking are allowed on back-end servers but not on front-end servers.

Freedoc access control through OWA

While you may not have heard of freedocs, chances are you have used them before. If you have ever dragged and dropped a document or a file directly into an Exchange folder (as opposed to attaching it to a message or post), you have used freedocs. Freedocs is the term given to stand-alone data in the information store. Because the dropped file is not an attachment of a message, it is considered a "free document" or a freedoc.

Freedocs are not new to Exchange 2003; they were present in all prior versions of Exchange. For example, in Exchange 2000, freedocs became accessible via OWA URLs (e.g., http://ex2k3/public/training/ exchange2003/intro_to_e2k3.doc). What is new to Exchange 2003 (as part of Secure by Default) is the ability to control access to freedocs through these OWA URLs. Here is a registry entry you can add to your OWA servers to control access.

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: EnableFreedocs
Value: 0, 1, 2, or 3 (dec)

If EnableFreedocs is not present or is set to 0, freedocs are completely blocked in OWA. Because the value is not present by default, freedocs are blocked out-of-the-box in OWA. When EnableFreedocs is set to 1, freedocs are accessible only when accessed directly via a back-end server; freedocs will not be accessible to OWA users connecting through a front-end server. If you set the value to 2, freedocs will be accessible from back-end servers and from any front-end server configured with a Host Header entry that matches the following registry on the back-end server.

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: AcceptedAttachmentFrontEnds
Type: REG_SZ
Value: comma-delimited list of FE servers, e.g.,,

Finally, when EnableFreedocs is set to 3, freedocs are accessible to all OWA users.

OWA cookie timeout

In Chapter 5, I described FBA, which makes using OWA more secure. FBA uses cookies authentication; that is, it stores the user credentials in a cookie that expires after a predetermined amount of time. In Chapter 6, I detailed the default session inactivity timeout settings for trusted (private) computers and shared (public) computers (theTrustedClientTimeout and PublicClientTimeout settings). In addition to idle timeouts, you can also specify a timeout value for the FBA cookie. To do this, add the following registry entry to the OWA server.

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: KeyInterval
Value Data: Timeout value (in minutes)

You can set KeyInterval to any value between 1 and 1440 (between 1 minute and 24 hours). If you add this registry entry, you will need to stop and restart the World Wide Web Publishing Service for the change to take effect.

Enhanced OWA segmentation

Exchange 2000 Service Pack 2 introduced a new feature called OWA segmentation. OWA segmentation, which is described in Microsoft Knowledge Base article 311154 (among other places), enables administrators to selectively enable and disable specific OWA features. OWA can be segmented or a per-user or per-server basis, with user settings taking precedence over server settings. There are a variety of reasons to segment OWA; for example, some organizations do not want users to have access to all OWA features because of security reasons or training concerns. Monetary reasons also exist—application service providers that sell hosted Exchange services may want to segment OWA and sell both a lite version and a full-featured version of OWA. This is sometimes referred to as tiered licensing or provisioning.

Per-server segmentation is performed by adding a specific hexadecimal value to the registry of the mailbox server, as shown here.

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: DefaultMailboxFolderSet
Value Data: See Table 10.1

Per-user segmentation is performed by configuring the msExchMailboxFolderSet attribute in Active Directory. This is an attribute of all mailbox-enabled users. In Exchange 2000, this attribute did not exist prior to Service Pack 2. To segment OWA you had to manually extend the Active Directory schema using OWASCHEMA.VBS, which added this attribute. Because this was a manual process, it is possible that your Exchange 2000 forest does not contain this attribute. However, as soon as Exchange 2003 FORESTPREP is performed, this attribute will be added.

Both DefaultMailboxFolderSet and msExchMailboxFolderSet are decimal values based on the bit masks shown in Table 10–1. Each bit mask corresponds to an individual OWA feature. Create a list of the features you want to enable, and add together their bit mask values. Then enter this sum as the decimal value in the registry or in Active Directory. Many of these values existed in Exchange 2000 Service Pack 2 and later; values that are new to Exchange 2003 have a checkmark in the New to Exchange 2003 column.

Once you have added all of the hex values, enter the sum in the appropriate place. For example, if you want to enable access to only the Messaging and Calendar features, you would use the following formula:

0x00000001 (Messaging)
+ 0x00000002 (Calendar)

You would then enter 0x00000003 in the registry or in Active Directory, depending on where you want to configure this.

Table 10-1 OWA Segmentation Values

Exchange Feature Bit Mask Value (Hex) New to Exchange 2003
All Features 0xFFFFFFFF -
Calendar 0x00000002 -
Contacts 0x00000004 -
Journal 0x00000010 -
Junk Email 0x00010000 x
Messaging 0x00000001 -
New Mail 0x00000100 -
Notes 0x00000020 -
Public Folders 0x00000040 -
Reminders 0x00000080 -
Rich Client 0x00000200 -
Rules 0x00004000 x
S/MIME 0x00000800 x
Search Folders 0x00001000 x
Signature 0x00002000 x
Spell Check 0x00000400 x
Tasks 0x00000008 -
Themes 0x00008000 x

Enabling public folder replies in Exchange 2003 OWA

By design, unless you are accessing OWA through a front-end server (and not directly via a back-end server), you will not be able to use the Reply, Reply All, or Forward functions for messages contained in public folders. While you'll be able to reply to and forward all messages in your mailbox regardless of how you access OWA, unless you go through an Exchange 2003 front-end server, you will not be able to take these actions for public folder messages.

In addition to these restrictions, by default there is a 2MB limit for all messages sent via a reply or forward action. You can override this limit by adding the following registry entry to your front-end servers, which specifies the allowable maximum size.

Location: HKLM\System\CurrentControlSet\Services\MSExchange\OWA
Value: maxPFReplyForwardSize
Value Data: X
For the maxPFReplyForwardSize entry, X is the maximum size you want to set in kilobytes.

7 tips in 7 minutes: Exchange Server 2003 tips and tricks

 Home: Introduction
 Tip 1: Tuning Exchange Server 2003 overview
 Tip 2: Exchange 2000 vs. Exchange 2003 tuning parameters
 Tip 3: Exchange 2003 tuning parameters -- Outlook Web Access
 Tip 4: Exchange 2003 tuning parameters -- Microsoft Outlook
 Tip 5: Exchange 2003 tuning parameters -- Exchange Server
 Tip 6: Must-have Exchange Server 2003 tools
 Tip 7: Exchange Server administration resources and links

 Microsoft Exchange Server 2003 Distilled This chapter excerpt from Microsoft Exchange Server 2003 Distilled by Scott Schnoll, is printed with permission from Addison-Wesley Professional, copyright 2004.

Click here for the chapter download or purchase the book here.

This was last published in June 2007

Dig Deeper on Outlook Web Access



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.