Blog Post

Exchange Team Blog
3 MIN READ

'Requesting data from the Exchange server...' or 'Outlook is trying to retrieve data…' client messages

The_Exchange_Team's avatar
May 25, 2005

Based on the questions that we got on another post, it seemed appropriate to address the "Requesting data from the Exchange server..." or "Outlook is trying to retrieve data…" client popup messages in a separate post. While we have touched upon this subject in several posts in the past, it would be good to bring it together.

The "Requesting data" popups are what we call "RPC Dialog Popups" or "RPC cancel requests". They are usually an indication that the client is taking unusually long time to receive information back from the server, or contact the server.

"Requesting data" popups can be seen on Outlook 2002 or Outlook 2003 versions (the earlier versions of Outlook client will simply hang in the situations that will kick off the popup on later versions of Outlook). The wording of the popup will vary depending on your Outlook version.

The reason why this particular problem is tricky to troubleshoot is this: while the popup itself is an indication that the client it taking a long time to get some information from the server, this delay can be caused by many things. Some of them are:

   - Exchange server performance problems
   - client (or add-in) problems
   - network related issues
   - large number of items in mailboxes
   - Active Directory related issues (performance issues etc)

When trying to identify the cause of those problems, it is usually the best to figure out the scope of the problem first. Problem scope might tell you a lot about the cause itself. For example, if all (or majority) of your clients are experiencing issues, then the problem is most likely server related (or network on the server side related). If there is a subset of users that are seeing those problems - it is best to try figure what is different about those clients as opposed to other clients you might have. Looks for commonalities, such as - they are all connecting through a specific VPN server, over a specific switch, they are all on the same subnet, they are using the same add-in, etc. Finding the common ground is not always simple but it is usually worth the trouble.

Additionally, the server mentioned in those popups can also be one of your Domain Controllers, not just Exchange servers. Or it could be your dedicated public folder server, and not your mailbox server. Make sure to understand what clients are having hard time communicating with.

There are several resources that will help you with troubleshooting this. For example, here is a general troubleshooting article that goes into different causes of this problem and has specific troubleshooting steps:

839862 How to troubleshoot the RPC Cancel Request dialog box in Outlook 2003 or 

Here is an article that talks about specific server-side problems that can manifest themselves in the form of RPC popups on the client side:

328880 Troubleshooting Public Folder Performance Issues Related to ACL 

Talking about server performance problems, we in Support Services have seen a lot of cases where performance problems were caused by Disk I/O bottlenecks on Exchange servers. Hardly ever we are seeing cases where memory or CPU are the performance bottleneck on Exchange servers. Because of that, I wanted to link to several very good resources on starting to figure out if disk latency is the problem you are having:

A few basic concepts in disk sizing 

Some more thoughts on disk IO and calculations... 

Client add-ins combined with the mailbox sizes (and numbers of items that are in specific mailbox folders) can also have an impact on your client performance. The following blog post talked about that a bit more:

Recommended Mailbox Size Limits 

Additionally, using the Exmon tool can help you log and analyze usage patterns of your MAPI clients. We have used this tool multiple times to identify the clients that were generating excessive amounts of traffic to and from the server.

I also mentioned Active Directory related issues above. If your clients are seeing popups with names of domain controller/global catalog server, it would be good to look into the performance of that server too. It is possible that the server is so overburdened by client requests, that it has hard time answering client requests for GAL lookups. This online book can help you with figuring how many Global Catalogs you might need in your Exchange organization, as far as client access is concerned.

Hope this was helpful! While this post might not provide the ultimate answer for every RPC popup case, it should help you in many!

- Nino Bilic

Updated Jul 01, 2019
Version 2.0
  • I read in similar discussions that you can tell from the popup and the servername if your issue is AD (GC) related or not.

    A servername in the FQDN format would indicate AD/GC problems. With a NETBIOS name the Exchange box itself is the most likely cause.

    Can you confirm these assumptions?
  • Hi there, Sorry this is completely off topic.
    I've been trying to find an email address or a web form to submit an issue we are having with OWA on Exchange 2003. Simply put emails with subjectlines that contain accented characters are unviewable via the web. The URL escaping for the accented character means that it is 2 % encodings. Meaning when the server decodes the subject line submitted it does not find the mail. The mails in question are viewable via Outlook fine.

    Cheers,
    Dan.
  • Just the same pop-up would appear on all the clients [Outlook 2003], found that the issue was also related to:

    1. Exchange Server NIC was at "Auto Detect".
    2. Event 9548 [Missing MasterAccountSID], ran NoMas and cleared 'em.

    Rahul
  • Michael,

    It is not that simple anymore... FQDN could be both Exchange (with OL 2003 client) or a DC/GC. On the other hand, if you have name resolution issues, it is possible that you see short name of the DC/GC too. It's really figuring out what that name is that OL client is poping up that will get you places.
  • Hey Nino,
    Thanks for the article. I noticed that you stated that the rule regarding FQDN versus Netbios name is "not that simple anymore". Does that mean something changed in OL2k3? Let me know.
  • M3TG :)

    Yes - things have changed a bit with OL2003... that's because if you go and look at your OL profile, the Exchange server name is now actually stored in the FQDN form, not the Netbios name form anymore...

    Additionally, name resolution problems can cause your problems that when you would WANT to see the FQDN instead of Netbios - you do not - so the length/format of the name in the popup by itself is not a "foolproof" indicator.