The following is Tip #11 from "25 Exchange 2003 Tips in 25 minutes." This content is excerpted from Scott Schnoll's...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
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|
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
Value Data: 1 (dec)
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
MAPI compression (referred to internally as AirMAPI) 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.
Value: Rpc Compression Enabled
Value Data: 0 or 1
Value: Rpc Compression Minimum Size
Value Data: X
Value: Rpc Packing Enabled
Value Data: 0
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.
Value: Maximum Polling Frequency
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.
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.