Now that we have gone over the legacy tuning parameters from Exchange 2000 that need to be removed, let's dive...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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
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.
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
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
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).
Value Data: 0, 1, or 2 (dec)
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
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.
Value: 0, 1, 2, or 3 (dec)
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.
Value: comma-delimited list of FE servers, e.g., www.something.com,www.somethingelse.com
EnableFreedocs is set to 3, freedocs are accessible to all OWA users.
OWA cookie timeout
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.
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.
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.
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:
+ 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|
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 For the
Value Data: X
maxPFReplyForwardSize entry, X is the maximum size you want to set in kilobytes.
7 tips in 7 minutes: Exchange Server 2003 tips and tricks
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
|This chapter excerpt from Microsoft Exchange Server 2003 Distilled by Scott Schnoll, is printed with permission from Addison-Wesley Professional, copyright 2004.|