Exchange Server Parameters

By Scott Schnoll 19 Apr 2004 | SearchExchange.com

Digg This!     StumbleUpon     Del.icio.us

The following is Tip #12 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.

Controlling Out-of-Office Messages

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 e-mail 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.

Location:
HKLM \System \CurrentControlSet \Services \MSExchangeIS \ParametersSystem
Value: SuppressOOFsToDistributionLists
Type: REG_DWORD
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 SuppressOOFs ToDistributionLists 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 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 e-mail account does not exist at the organization this message was sent to. Check the e-mail 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.

Location:
HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent
Value: RenderDSNsAsMessages
Type: REG_DWORD
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.

Reenabling the M: Drive

Exchange 2000 is 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 re-enable the M: drive, you can do so by adding the following registry entry to your Exchange server.

Location: HKLM\System\CurrentControlSet\Services\ExIFS\Parameters
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 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.

Location: HKLM \ System \ CurrentControlSet \ Services \ MSExchangeIS
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.

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.

Digg This!     StumbleUpon     Del.icio.us

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary