In versions of Microsoft Outlook that are earlier than Microsoft Outlook 2002, Outlook periodically appears to stop responding (hang) when users send e-mail messages, receive e-mail messages, check appointments, or create appointments. When Outlook stops responding, users see an hourglass until Outlook has the information that it requires. The types of data that Outlook retrieves during this period include information in the user's mailbox, information in the user's public folders, free/busy information, and directory look-ups (check-name). The server that Outlook queries for this information is either a Microsoft Exchange Server computer or a global catalog server. If the server name appears as a NetBIOS name, the data is being retrieved from an Exchange Server computer. If the server name appears as a fully qualified domain name (FQDN), the data is being retrieved from a global catalog server.

The remote procedure call (RPC) Cancel Request dialog box is a feature that was added in Microsoft Outlook 2002. With this feature, users can see the server that Outlook is accessing. Additionally, by using the Cancel Request dialog box, users can cancel the data retrieval.

When Outlook 2002 and later versions request data from an Exchange Server computer, Outlook calls a function that wraps the RPC to the server. This new wrapper is the Cancelable RPC wrapper. By default, the Cancelable RPC wrapper starts a timer and issues the RPC. When the RPC is complete, the wrapper closes the timer, cleans up, and quits. However, if the RPC for data takes more than 5 seconds to return the data, the wrapper produces the Cancel Request dialog box. The Cancel Request dialog box remains on the screen until the RPC is answered or until the user clicks Cancel. If the action that the user performs in Outlook causes multiple RPCs to be made, the user may receive a Cancel Request dialog box for each RPC.

Although the Cancel Request dialog box was intended to improve the user experience by providing server information when Outlook stopped responding, many users interpret this message as an error message and contact their help desk for more information, instead of understanding that the Cancel Request dialog box occurs as an ordinary part of Outlook and Exchange interoperation. On the fastest network with the best hardware and the best architecture, sometimes an RPC takes more than 5 seconds to obtain a response. If the Cancel Request dialog box appears only occasionally, 'extensive troubleshooting is not required and is not productive. However, if users receive the Cancel Request dialog box frequently and for extended periods, there may be a performance issue with one of the servers or a problem with the network. This article discusses troubleshooting steps that you can use to determine the root cause of frequent Cancel Request dialog boxes.

For more information about how to disable the Cancel Request dialog box feature or how to increase the time-out value if you experience frequent network congestion or other related issues, click the following article number to view the article in the Microsoft Knowledge Base:

If the Cancel Request dialog box appears frequently or for extended periods, follow these steps.

Gather troubleshooting information

To gather troubleshooting information, follow these steps:

Gather the following information about what the user is doing when the user receives many Cancel Request dialog boxes:

Is the user browsing a Public Folder that is located in another Administrative Group without having a replication of this folder in their own site?

Is the user opening a meeting with many attendees?

Is the user creating or updating a meeting to check the free/busy information for the attendees?

Consider the Active Directory and Exchange architecture of your environment. Answer the following questions:

Are the global catalog servers located locally or remotely?

Does connectivity to the remote site pass through routers and through firewalls?

Are there dedicated Public Folder servers?

Where are the system folders homed?

The answers to these questions may provide insight about the root cause of the issue.

Review the event logs of the Exchange Server computer

You may notice events in the application event log or in the system event logs. These events may indicate connectivity issues between your Exchange Server and your global catalog server. If you have migrated from Exchange 5.5 to Exchange 2000 or to Exchange 2003, you must determine whether your Exchange Server computer or your dedicated Public Folder server is generating events that are similar to the following events:

Event 9551Event Type: WarningSource: MSExchangeISPublicEvent Category: GeneralDescription: An error occurred while upgrading the ACL on folder Public Folder name located on database First Storage Group\Public Folder Store. The
Information Store was unable to convert the security for /O=Exchange organization name/OU=Administrative Group/CN=Recipients container name/CN=User account name into a Windows 2000 Security Identifier. This may be caused by latency in the Active Directory Service. If it is caused by latency, wait until the user record is replicated to Active Directory, and then try to access the folder (it will be upgraded in place). If the specified object is not replicated to Active Directory, use the Microsoft Exchange System Manager or the Exchange Client to update the ACL on the folder manually. In this example, the access rights in the Access Control Entry (ACE) for this DN are 0x41b.

If you see these events, you are probably experiencing an issue with unknown accounts. These unknown accounts are sometimes named "zombie users."
For more information, click the following article number to view the article in the Microsoft Knowledge Base:

How to troubleshoot public folder performance issues that are related to ACL conversions in Exchange 2000 and in Exchange 2003

A hotfix is available to modify the way that Exchange Server 2003 handles a disabled Active Directory user account that is associated with an Exchange Server 2003 mailbox.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:

A hotfix is available to modify the way that Exchange Server 2003 handles a disabled Active Directory user account that is associated with an Exchange Server 2003 mailbox

If you see many 1016 events in the application event log on the Exchange Server computer, your issue may be caused by users who are creating and updating calendar items. In this scenario, it may be a good idea to disable the Planner Options feature for testing purposes. Planner Options is a feature that was originally introduced in Outlook 2002. Planner Options gathers much more data than earlier versions of Outlook if the Scheduling tab is clicked when a user creates, updates, or reads about a meeting. If disabling this feature resolves the excessive RPC dialog boxes, you must determine if disabling this feature works for your business. If the Planner Options feature is disabled, the user can see the attendee's free/busy information, but additional details are not viewable.

How to turn off the Planner Options feature

Follow these steps to turn off the Planner Options feature:

On the Tools menu, click Options.

On the Preferences tab, click Calendar Options.

In the Calendar Options dialog box, click Planner Options.

In the Meeting Planner section, click to clear the Show popup calendar details check box.

Click OK three times.

For more information about Planner Options and about the Event ID 1016 that you receive on your Exchange server, click the following article number to view the article in the Microsoft Knowledge Base:

A 1016 event entry appears in the application log after you upgrade to Outlook 2002

Turn off Instant Messaging integration in Outlook

If moving between messages in Outlook is slow and causes the Cancel Request dialog box to appear, turn off Instant Messaging in Outlook. To do this, use one of the following methods.

Method 1

On the Tools menu, click Options, and then click the Other tab.

Under Person Names, click to clear the Enable Person Names Smart Tag check box, and then click to clear the Display Messenger Status in the From Field check box.

Click OK.

Method 2

Administrators can also turn this feature off by changing the Enabled registry value to 0 in the following registry subkey:

HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\IM

To do this, follow these steps.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

Troubleshoot performance issues

To troubleshoot performance issues, gather data by using Performance Monitor. It is common to experience RPC latency when either an Exchange Server computer or a global catalog server is experiencing performance issues.

If the RPC dialog references an Exchange Server (NetBIOS name), configure Performance Monitor to monitor the following counters in real time:

Note It is a good idea to run Performance Monitor from a remote workstation that has lots of free disk space.

Typically, it is a good idea for the RPC Requests counter to be lower than 10. If it is higher than 25, this is an indicator of a resource bottleneck. Only 100 requests can be handled at the same time. If the RPC Requests reach 100, the client will experience refused connections.

The RPC Averaged Latency counter displays the average time that it takes the server to respond to client requests. The value of the counter is typically less than 50 milliseconds in typical operations. If the value is consistently more than 50 milliseconds with Outlook 2002 or Outlook 2003 when most of the users are in Online Mode, this means that the Information Store is taking a long time to process user requests. If most Outlook 2003 users are in Cached Mode, this threshold increases to 100 milliseconds. Typically, if the Information Store is taking a long time, there is a disk bottleneck.

The recommended values for the Avg Disk Sec/Read counter and for the Avg Disk Sec/Write disk counter are as follows:

Good < 20 msec

Fair < 30 msec

Poor < 40 msec

Cache/Exec < 1 msec

Cache/Good < 2 msec

Cache/Fair < 4 msec

If the counters are greater than .050 seconds (50 msec), there is most likely a disk bottleneck.

Note It is not unusual to see brief spikes that are greater than .050, but if you are seeing counters greater than .050 for 30 to 60 seconds at a time, there probably is a problem.

To determine if there is a problem with the current disk queue length, see how frequently the value drops to zero. If the queue length drops to zero periodically, such as four times per minute, the queue is being cleared, and you probably do not have a disk bottleneck.

it is a good idea for the Log Record Stalls/sec counter to remain at 0. If you are seeing a high number of log stalls on an Exchange 2000 Server computer, change the value of the msExchESEParamLogBuffers property.
For more information about changing the value of the msExchESEParamLogBuffers property, click the following article number to view the article in the Microsoft Knowledge Base:

ESE log buffers that are set too low can cause the Microsoft Exchange Information Store service to stop responding

If the Cancel Request dialog box references a global catalog server that has a fully qualified domain name (FQDN), configure Performance Monitor to monitor the % Processor Time counter on the global catalog server to make sure it is not too high. A value such as > 90 over a sustained period is too high. If the % Processor Time counter is high, you have an overloaded global catalog server.
For additional information about using Performance Monitor, click the following article number to view the article in the Microsoft Knowledge Base:

How to capture performance data from a remote Windows 2000 computer using System Monitor

Troubleshoot network issues

Use Network Monitor or another protocol sniffer to determine whether you are experiencing problems with your network.

Discussing how to configure and to use a protocol sniffer is outside the scope of this article. However, if you are already familiar with using such a utility, it is a good idea to reproduce the issue while you monitor traffic on both the client and the server at the same time. When you analyze the data, look for retransmits. A retransmit occurs when the client or the server has to send the same packet of information again, typically because the packets are being dropped between the client and the server. Therefore, when you analyze network captures, determine if the client request is actually getting to the server or if the server is responding but the response is lost before the client receives it.

How to change RPC dialog box pop-up behavior

For more information about how to disable the Cancel Request dialog box feature or how to increase the time-out value if you experience frequent network congestion or other related issues, click the following article numbers to view the articles in the Microsoft Knowledge Base:

How to change the behavior of the Cancel Request dialog box in Outlook 2003

The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.