Exchange Server 2003 Tips and Tricks

This chapter is from the book

Microsoft Exchange Server 2003 Distilled

Learn More Buy

This chapter is from the book

This chapter is from the book 

Microsoft Exchange Server 2003 Distilled

Learn More Buy

Exchange 2003 Tuning Parameters

Now that we have gone over the legacy tuning parameters from Exchange 2000 that need to be removed, let's dive 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.

Outlook Web Access Parameters

OWA is highly configurable. We've discussed in earlier chapters some features (such as themes and spell-check management) that demonstrate this. 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 back-end 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 DisableAttachments 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 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.

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.

OWA Cookie Timeout

In Chapter 5, I described FBA, which makes using OWA more secure. FBA uses cookies authentication; that is, it stores the user credentials in a cookie that expires after a predetermined amount of time. In Chapter 6, I detailed the default session inactivity timeout settings for trusted (private) computers and shared (public) computers (the TrustedClientTimeout and 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.

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: KeyInterval
Type: REG_DWORD
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 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.

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

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:

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

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.

Outlook Parameters

In previous chapters, I wrote about the new features in Outlook 2003 specifically targeted at Exchange users. Features such as RPC over HTTP (which is really RPC over HTTPS), Cached Exchange Mode, and others help to greatly improve the overall experience for Outlook users. In addition to these new features, a variety of administrative options can be set to improve the experience for both Outlook users and Exchange administrators, such as improved alias matching, the ability to disable MAPI compression, control of RPC over HTTPS polling, and improved behavior regarding the ability to restrict access to Exchange based on the version of Outlook that is running.

Alias Matching

If you enter an alias into the TO, CC, or BCC fields in Outlook, before the message can be sent the recipients must first be resolved. Outlook would look up the information in the Global Address List and/or in a personal address book or in Outlook contacts. By default, any partial name that you enter is checked against three naming fields: first name, last name, and alias. Consider the following entries in the Global Address List.

First Name        Last Name         Alias
John              Doe               JohnD
Johnny            Roe               JohnR

If you enter “John” on any of the address field lines, Outlook will match both entries and ask you to choose which entry to use. Previous versions of Outlook enabled you to bypass duplicate entries by appending an equals sign (=) to the beginning of your entry. For example, to bypass duplicate entries and specify Johnny Roe, you would enter “=JohnR” into the address field. Because Johnny Roe's alias is JohnR, it is instantly matched.

Outlook 2003 improves this behavior by eliminating the need to use the equals sign if you have added the following Outlook registry setting.

Location: HKLM\Software\Microsoft\Exchange\Exchange Provider
Value: OAB Exact Alias Match
Type: REG_DWORD
Value Data: 1 (dec)

If the OAB Exact Alias Match value is not present or is set to anything other than 1, Outlook 2003 will behave like all other Outlook clients and will exactly match an alias only when the equals sign is used. If the value is present and set to 1, Outlook will resolve the exact alias without providing a list of possible matches.

MAPI Compression Settings

In Chapter 2, I wrote about a new feature called MAPI compression (referred to internally as AirMAPI) that is available when you use Outlook 2003 and Exchange 2003 together. AirMAPI compresses all content at the Exchange server before sending it to Outlook, which decompresses it. When AirMAPI is enabled, another feature called Buffer Packing is also enabled. With Buffer Packing, information sent from Exchange to Outlook is packaged in bigger, optimized buffer packets, which reduces the number of packets that ultimately need to be sent.

While AirMAPI and Buffer Packing provide some impressive performance improvements, they can hinder some troubleshooting efforts. When troubleshooting client-server issues, a common practice is to use a network sniffer such as Network Monitor to capture network traffic for analysis. Because AirMAPI is enabled by default, it can make troubleshooting more difficult because all of the data in the trace is compressed and therefore not readily discernable. Fortunately, you can use the following server-side registry entries to control and/or disable AirMAPI and Buffer Packing if needed.

Location:
HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Value: Rpc Compression Enabled
Type: REG_DWORD
Value Data: 0 or 1

Location:
HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Value: Rpc Compression Minimum Size
Type: REG_DWORD
Value Data: X
   
   Location:
   HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
   Value: Rpc Packing Enabled
   Type: REG_DWORD
   Value Data: 0
   

None of these entries exist by default, and therefore they need to be manually added if you want to configure or disable AirMAPI. If Rpc Compression Enabled is not present or is set to 1, AirMAPI compression is enabled. Any other value will disable it. The Rpc Compression Minimum Size entry is used to specify a minimum size for an RPC packet in order for AirMAPI to be used. If this value is not present, a default value of 1,024 bytes is used. In this example, X represents the desired minimum size in bytes.

Finally, you can selectively enable and disable Buffer Packing by using the Rpc Packing Enabled entry. If this entry is not present, a value of 1 is assumed and Buffer Packing is enabled. When this entry is set to 0, Buffer Packing is disabled.

When changing any of these settings, you will need to stop and restart the Information Store service for the change(s) to take effect. Because of the benefits provided by AirMAPI and Buffer Packing, I recommend disabling these features for troubleshooting purposes only.

RPC over HTTPS Polling

When making an initial connection to an Exchange server, Outlook registers itself for new message notifications. Whenever a new message is received in an Outlook user's mailbox, Exchange sends a notification to Outlook using UDP. This notification is essentially a small flag to the client that a new message is present and needs to be displayed. When Outlook receives the UDP notification, it retrieves the message from the Exchange server and displays it in the appropriate folder (e.g., the Inbox).

New message notifications are intended for Outlook clients that are running in either online mode or Cached Exchange Mode, and they won't work for Outlook clients using RPC over HTTPS. In fact, when using RPC over HTTPS, Outlook does not register for notifications (because it won't be able to receive them). Instead, Outlook clients using RPC over HTTPS use a polling mechanism to check for new messages. While polling is initiated by Outlook, the polling frequency is dictated by the Exchange server. Polling is not new to Outlook 2003; Outlook 2002 automatically reverts to polling if the UDP notification fails. However, new in Exchange 2003 is your ability to configure a polling interval for RPC over HTTPS clients.

By default, Outlook 2003 will poll every 60 seconds. You can change the frequency by adding the following registry entry to the Exchange server that contains the user's mailbox.

Location:
HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Value: Maximum Polling Frequency
Type: REG_DWORD
Value Data: X
   

For this value, X is the minimum number of milliseconds between polling intervals. If Maximum Polling Frequency is not present, a default value of 60 seconds (60000 when set in milliseconds) is used. Again, this is the minimum number of milliseconds between polling intervals, which means that polling does not take place every 60 seconds. Instead, polling will occur any time between the polling frequency interval and twice that interval. For example, if you set Maximum Polling Frequency to 90 seconds, polling will take place between 90 and 180 seconds after the last poll.

When configuring this value, keep in mind the following important information. First, Microsoft does not recommend lowering this value because of the performance hit to Exchange, Outlook, and the network. Therefore, you should not use a polling frequency less than 60 seconds. Second, you may not need to adjust polling at all because many user actions will actually check for the new message flag as part of internal operations. For example, if you switch folders or open a message, new items on the server will be displayed. This occurs because when Outlook sends necessary RPC requests to Exchange to effect the user action, the new message flag is checked and, if present, the new message notification is included in the RPC response sent back to Outlook.

Outlook Version Blocking

Both Exchange 2000 and Exchange 2003 support a feature that enables administrators to prevent specific versions of MAPI clients from connecting to and using Exchange. For example, if you want to allow only Outlook 2003 users to connect to your Exchange server, you would configure the registry on the Exchange server as described in Microsoft Knowledge Base article 288894. You can also use this feature to disable all MAPI access to an Exchange server (by specifically blocking all known MAPI clients) or to block unpatched versions of Outlook 2003 (or any other Outlook client) from using Exchange until they have all required updates.

After adding the appropriate settings to the registry, Exchange 2000 required you to stop and restart the Information Store service for the change to take effect. New in Exchange 2003 is the ability to dynamically read this value from the registry and apply it without having to restart the store. A background thread checks this value every 15 minutes, so the most you'll ever need to wait for this change to take effect is 15 minutes. Because the 15-minute cycle for the background thread is hard-coded, if you want the change to take effect sooner, you still need to cycle the Information Store service.

Exchange Server Parameters

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)² and delivery status notification (DSN) messages, reenable the M: drive, and designate a specific system for backfilling public folders.

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 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 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\ParametersSystemInternetContent
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

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\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.