Article

Outlook Web Access Parameters

Scott Schnoll

The following is Tip #10 from "25 Exchange 2003 Tips in 25 minutes." This content is excerpted from Scott Schnoll's book, "Microsoft Exchange Server 2003 Distilled," brought to you by © (2004) Pearson Education, Inc. Publishing as Addison-Wesley Professional.

    Requires Free Membership to View

Return to the main page for more tips on this topic.


OWA is highly configurable. 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.

Attachment Blocking

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 backend 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
Type: REG_DWORD
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.

Freedocs

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
Type: REG_DWORD
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 backend 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., www.something.com,www.somethingelse.com 

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

Enhanced 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 fullfeatured 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
Type: REG_DWORD
Value Data: See Table 10.1 

Per-user segmentation is performed by configuring the msExch MailboxFolderSet 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)
----------------------------------
0x00000003

 

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 E-mail 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

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
Type: REG_DWORD
Value Data: X 

For the maxPFReplyForwardSize entry, X is the maximum size you want to set in kilobytes.

 

 


Get more "25 Exchange 2003 Tips in 25 minutes." Return to the main page.

About the author: Scott Schnoll, an Expert on SearchExchange.com, is an MCT, MCSA and a long-time Microsoft Most Valuable Professional (MVP).

In addition to writing "Microsoft Exchange Server 2003 Distilled," he is a co-author of the upcoming "Exchange 2003 Resource Kit from Microsoft Press" and lead author for "Exchange 2000 Server: The Complete Reference."

Scott has written numerous articles for Exchange & Outlook Magazine, and is a regular speaker at Microsoft conferences, including MEC and TechEd, as well as industry conferences such as Comdex and MCP TechMentor, where he covers topics such as Exchange, clustering, Internet Information Services and security.

 

 


There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
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
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: