Slow updates to public folder all day event edits in cached mode

  • Thread starter Thread starter Elliot Mackenzie
  • Start date Start date
E

Elliot Mackenzie

I have noticed that all-day events created in an Outlook/Exchange public
calendar folder take a long time to update (up to five or six minutes).
The most irritating thing is that the edits do not appear in the
Outlook client instantly, and my customers have been double-editing and
running into a great deal of confusion as a result.

More precisely, I have discovered the following:
- This problem only exists for exchange connections in cached mode.
- Outlook 2003 has had this problem since the first release and
continues to have this problem with the latest service packs/patches.
- I have not observed the same problem with Outlook 2000/XP(2002).
- When not in cached mode, updates are immediate.
- Edits (for example to the appoinment's category) take a long time, but
the creation of an all day event is "instant".

This is the bit I can't figure out --->
Only all-day events/appointments defined in the grey bit up the top of
the calendar take so long to update: updates to normal appointments (eg
15 minute appointment in the middle of the day) are "instant".

Is this normal behaviour or is something broken?

Unfortunately the nature of this setup is that not running in cached
mode is not an option for a permanent solution.

Kind regards,
Elliot.
 
During more thorough testing I have noticed that normal appointments and
all-day events are both affected.

I have therefore come to the conclusion that this is a "feature", not a
bug. Is there a way to adjust/increase the the frequency with which
Outlook "checks-in" and synchronizes with exchange while operating in
cached mode? This is for a single remote client, and as such the
performance hit would be negligible at best.

Kind regards,
Elliot.
 
I have found the answer to my question. For future reference I have
included the solution below.

Kind regards,
Elliot.


(http://searchexchange.techtarget.com/originalContent/0,289142,sid43_gci959761,00.html)

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