Manage Learn to apply best practices and optimize your operations.

Exchange 2003 tuning parameters -- Exchange Server

Learn how to control Exchange Server out-of-office messages and delivery status notifications, re-enable the M: drive, and backfill Exchange public folders.

On an Exchange 2003 server you can configure a few additional parameters that provide you with additional levels of control. Some of these parameters have already been discussed in other chapters, such as the Recovery SG Override setting described in Chapter 8 and the OWA spell-check throttles described in Chapter 9. The additional parameters enable you to control out-of-office messages (OOFs) (see footnote2) and delivery status notification (DSN) messages, reenable the M: drive, and designate a specific system for backfilling public folders.

(Footnote2: In case you are wondering why people use OOF for out-of-office instead of OOO, it has to do with the original implementation of the term. Instead of the term out-of-office, people used to use the term out-of-facilities. Thus OOF is actually an acronym for out-of-facilities, but now it is generally used to mean out-of-office. Special thanks to KC Lemson at Microsoft for sharing this interesting trivia bit).

Controlling out-of-office messages in Microsoft Outlook

You are reading tip #5 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.

When an Outlook user enables the Out of Office Assistant to generate OOFs, an OOF is generated for messages sent to this user when his or her email address is explicitly listed in the TO or CC fields or when he or she is a member of a distribution list (or mailing list) listed in the BCC field. For a variety of reasons, you may wish to limit OOFs to those cases where a user is specifically listed in the TO or CC fields and not in a BCC field. This feature is particularly useful in situations where users are members of mailing lists managed by foreign (i.e., non-Exchange) messaging systems.

To suppress the generation of OOFs for BCC'd distribution lists, add the following registry entry to the Exchange server that contains the mailbox(es) you want to affect.

Value: SuppressOOFsToDistributionLists
Value Data: 1

If the SuppressOOFsToDistributionLists value is not present or is set to anything other than 1, the behavior will remain unchanged. However, when set to 1, this registry entry will suppress OOFs for BCC'd distribution lists. When you use this feature, keep in mind that an OOF will still be sent in cases where a message is sent to an individual recipient using the BCC field only (i.e., no recipients in TO or CC fields) even if SuppressOOFsToDistributionLists is enabled. This applies only if the recipient is in the BCC field and the TO and CC fields are blank. If another recipient is present in the TO or CC fields, SuppressOOFsToDistributionLists will suppress the OOF.

Controlling Exchange Server delivery status notifications

When an Exchange user sends a message to an external recipient whose messaging system is configured to use custom nondelivery reports (NDRs), the user may not receive the custom NDR and instead may receive a standard NDR similar to the following one.

From: System Administrator
To: <sender name>
Subject: Undeliverable: <subject>

Your message did not reach some or all of the intended recipients.

Subject: <subject> 
Sent: <date> <time>

The following recipient(s) could not be reached: 
<recipient> <date> <time>
The email account does not exist at the organization this
message was sent to. 
Check the email address, or contact the recipient directly to 
find out the correct address. 
<Domainname #5.1.1>

A standard NDR is received instead of the foreign system's custom NDR because the Exchange information store reformats the message as the message is converted to a MAPI message. When this happens, any customizations made to the NDR are lost. (Note though that this happens only with MAPI clients; if you access the message using a non-MAPI client instead, the custom NDR will be preserved.)

In Exchange 5.5 and earlier versions, the custom NDR was also preserved even when viewed by a MAPI client. Exchange 2000 added support for the Report content type as prescribed in RFC 1892, and this effectively broke custom NDRs. Based on feedback from its customers, Microsoft allowed this behavior to be modified by using a registry entry on the Exchange server for customers running Exchange 2000 Service Pack 3 plus the hotfix from Microsoft Knowledge Base article 812806 or later. The code changes in the hotfix have been rolled into Exchange 2003, enabling you to add the following registry entry to your Exchange server to override the conversion behavior and render the NDRs as intended by the foreign mail system.

Value: RenderDSNsAsMessages
Value Data: 1

If RenderDSNsAsMessages is not present or is set to anything other than 1, the custom NDR will not be preserved. If the registry entry is set to 1, the custom NDR is preserved and viewable by MAPI clients. This change takes effect dynamically so there is no need to restart the server or any services.

Re-enabling the M: Drive to your Exchange server

As I wrote in Chapter 3, Exchange 2000 shipped with a feature known as the Exchange Installable File System (ExIFS, often simply called IFS). ExIFS is a kernel-level driver that exposes some of the data from the Exchange information stores to the Windows file system through a drive letter mapping. By default, the drive letter used was M. If this letter was already in use for a drive mapping, the next available letter was used (e.g., N, O, and so on). The ExIFS drive mapping was not the same as a local or network drive, although it was widely misinterpreted as one. Many administrators treated the M: drive like a physical disk; some administrators scanned the drive with antivirus scanners or took backups of it, mistakenly believing they were backing up their Exchange data. Others set permissions on Exchange items through the file system. Unfortunately, these actions were not supported, and in most cases they actually damaged the information store databases.

Remember, the whole idea of product evolution is to design and evolve the product in a way that keeps support calls to an absolute minimum. With ExIFS, the exact opposite was happening; administrators with damaged databases posted frantic requests for help in Microsoft's newsgroups, while at the same time PSS was receiving a high volume of calls on this same issue. To address this problem, and more importantly to prevent it from happening again with Exchange 2003, Microsoft changed the default behavior for ExIFS and left it turned off. Whether you upgrade from Exchange 2000 or install a fresh copy of Exchange 2003, the drive mapping for ExIFS will not be present unless and until you enable it.

From a best-practice perspective, you should not enable the ExIFS drive mapping unless you have a very specific reason you need to do this. If you do reenable the M: drive (regardless of what drive letter is actually assigned), you should be aware of the following caveats.

  • Only non-MAPI content should be accessed via this drive. Accessing MAPI data via ExIFS is not supported and could damage your store.
  • You should not share out the M: drive or any folders under this drive. In other words, do not create a Windows file share for SMB-based access. If you need to expose the non-MAPI data to network users, you can use Web Folders instead.
  • If you enable the drive mapping, you will need to reboot Exchange every time you install an update or an upgrade (e.g., a new service pack).
  • The same restrictions in Exchange 2000 still apply. Do not scan the M: drive; do not use backup software to back up the M: drive; and do not set any ACLs or other permissions on the M: drive.

If after reading this far you still want to reenable the M: drive, you can do so by adding the following registry entry to your Exchange server.

Location: HKLM\System\CurrentControlSet\Services\
Value: DriveLetter
Type: REG_SZ
Value Data: M

If you prefer to use something other than M for the drive letter, simply enter the desired letter for the value data. You will then need to reboot the Exchange Information Store service for this setting to take effect. Also, if you decide to later disable this drive mapping, simply removing the registry entry and cycling the information store may not be sufficient. You may also need to use the procedure documented in Microsoft Knowledge Base article 305145.

Backfilling the Exchange public folder

Whenever any update is made to an Exchange public folder, a change number (CN) is assigned to the folder, which is used by the replication engine to track folder updates. A set of CNs is called a CNSet. Whenever one Exchange server sends updates to another Exchange server, it includes its CNs. The receiving server reads the sending server's CNs to determine whether any changes have been made and whether the receiving server is missing any data as a result of the change(s). If it is missing data, backfilling will occur.

Backfilling provides a recovery mechanism in a variety of situations, such as when a public store has been restored from a backup or has been offline for some time, or when replication messages are somehow lost in transit. If a public folder store detects a gap in any folder's CNSet, it issues a Backfill Request message. The server to whom the request is sent responds with a Backfill Response message that includes the missing data.

A new feature in Exchange 2003 is a setting that provides you with the ability to override the default public folder backfill algorithm and designate a preferred server for backfill requests. This setting can be implemented as an Active Directory attribute or as a registry setting on the Exchange server. Before an Exchange server sends a backfill request, the Active Directory attribute is checked first. If the attribute is null, the registry is checked. If the entry is not present, the default algorithm for public folder backfilling is used.

If you want to use the Active Directory attribute, enter the GUID of the desired backfill server to the msExchPreferredBackfillSource attribute on the Exchange server's public information store object (e.g., on the server sending the Backfill Request message, not on the one you want to use as the backfill server). If you prefer using the registry, add the following entry on the server sending the Backfill Request message.

Value: Preferred Backfill Source
Type: REG_SZ
Value Data: Public Folder Store GUID of desired backfill server

Both the Active Directory attribute and the registry change take effect dynamically (they are checked as part of each backfill request), so there is no need to stop or start anything.

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.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.