Outlook slow to open other users calendar

[Monza]

Server is Exchange 2003 and clients are using Outlook XP (2002 with SP3). The problem is some users when opening someone else's calendar takes between 10 and 20 seconds. They report that sometimes it opens almost instantly, but usually they have the delay. Opening the calendar a second time, it is always instant, cached I guess. Opening the same people's calendar from my PC, it always opens instantly, so don't belive it is a server issue.

Any ideas on how to troubleshoot this one? Is there anyway to see what exactly Outlook is doing during the delay?

 

[Monza]

*bump*

 

[PScottC]

Do you have multiple exchange servers?

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers

 

[Monza]

Yes, we do but didn't think that mattered as these people are only trying to open calenders within the same domain, ie same Exchange server.

 

[Monza]

*bump*

 

[PScottC]

Honestly... I've seen this issue on and off for the 4 years I've been working with Exchange. I can't explain it and at this point I just expect it to happen. Usually users will get the "trying to connect to Exchange Server" pop-up for a couple of seconds and then it goes away.

It's typically very noticable when users are on different servers or if they are accessing the server over a wan link.

I wish I could be more helpful.

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers

 

[Monza]

Thanks for your help PSC, I am trying to fob it off to my manager as 'one of those things' but she is being stubborn.

One thing I did find is that after turning on access control diagnostic logging for the mailboxes I get the following error message pop up 4 or 5 times, these error messages span the 15 second delay the user experiences:

Event Type: Warning
Event Source: MSExchangeIS Mailbox Store
Event Category: Access Control
Event ID: 1029
Date: 4/4/2005
Time: 8:05:39 AM
User: N/A
Computer: EXCHANGESERVER
Description:
usera@domain.co.nz failed an operation because the user did not have the following access rights:

'Delete' 'Read Property' 'Write Property' 'Create Message' 'View Item' 'Create Subfolder' 'Write Security Descriptor' 'Write Owner' 'Read Security Descriptor' 'Contact'

The distinguished name of the owning mailbox is /O=FCL/OU=FB/CN=RECIPIENTS/CN=USERS/CN=USERB. The folder ID is in the data section of this event.


I tried giving the user owner access instead of reviewer access, no difference. Technet says I can safely ignore this message.

 

[PScottC]

Try checking the ACL on the mailbox in ADUC on the Exchange Advanced Tab. Is "Self" given the "Read" and "Full mailbox access" permissions? If not, add it.

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers

 

[chrisstyles]

Just a suggestion..

We have had real problems with requesting data which were only really solved upgrading to outlook 2003.

We switched all users over to Outlook 2003 using the licenses on the new cals and turned on Cache Mode.

This gave problems openeing other calendars. Sometimes it took a long time, and other times it just came up with the folder could not be found.

We found adding the /cleanfreebusy to all users outlook program shortcuts resolved the issues.

Chris Styles

NT4/2000 MCSE

 

[Monza]

Thanks again PSC, but Self does indeed already have "Read" and "Full mailbox access" permissions.

I will look into command line switches, atm upgrading to Outlook2003 is not an option.

 

[WhoKilledKenny]

I believe that this is by design. Has to do with RPC timeout. Please read below, info taken from MS Website. Our users experience this issue from time to time. According to Microsoft this is not an issue. It just causes a lot of calls to the help desk.


Because of user feedback, the Outlook product group added the "retrieving data" message in Outlook 2002.

Mechanics

In Outlook 2002 and Outlook 2003, when Outlook requests data from a Microsoft Exchange computer, Outlook calls a function that wraps the remote procedure call to the Exchange computer. This wrapper is the CancelableRPC wrapper. By default, this wrapper starts a timer and then issues the remote procedure call. The timer stops when a response is received. However, if the remote procedure call for data takes more than five seconds to return the data, the wrapper produces the “retrieving data” message. The dialog box that contains the message remains on the screen until the remote procedure call is answered or until the user clicks Cancel. If the action that the user performs in Outlook creates multiple remote procedure calls, the message could appear one time for each remote procedure call.

Because of the design of this feature in Outlook 2002, the Outlook 2002 user interface (UI) stops responding while the “retrieving data” message is displayed in a dialog box. In Outlook 2003, this problem does not occur. When the “retrieving data” message is displayed in a balloon in Outlook 2003, users can continue to use Outlook.

You receive this message as part of the standard interoperation of Outlook and Exchange. Even on the fastest network that has the best hardware and architecture, some remote procedure calls will take more than five seconds to obtain a response. This is a simple fact, and the appropriate expectations should be set with users. If the message appears only occasionally, no extensive troubleshooting is required. Trying to troubleshoot when the message appears only occasionally is not likely to be productive.

Remote procedure call is a sequential transport. When a remote procedure call is made, it must be answered, or the remote procedure call session must be restarted. This is different from a protocol like the Internet Protocol (IP) where packets can be received in any order and then reconstructed on the other side. This understanding is fundamental when you try to troubleshoot problems that are related to remote procedure calls that can be canceled from the dialog box or the balloon that contains the "receiving data" message.

 

[Monza]

Thanks, interesting read.

Full article here,

http://support.microsoft.com/?kbid=892764

Problem for me is that the delay for the users is not infrequent, it is happening everytime and can be as long as 30 seconds.

 

[PScottC]

Is this happening at any other time besides when accessing other users' calendars? There was a very long thread here about a year and half ago about this type of issue. Most people having the issue were running servers with Broadcom Gigabit NICs. In this line of thought, try locking the NIC port speed on the server or changing to a known good NIC, like a 3Com 10/100 PCI card.

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers