Outlook Web Access Parameters |
 |
By Scott Schnoll
19 Apr 2004 | SearchExchange.com |
 |


|
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. 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.
');
// -->
|
 |
|
 |