Calendar tracking not consistant when meetings booked by delegate in cached mode

Question

Situation:
Exchange 2010 Sp3
Outlook 2010 SP1 Cached mode, with delegate having full access to manager's mailbox with auto mapping on.
Whe the delaget books a meeting in the managers callander.  Some of the response are not relected in the tracking on the meeting.  The patern is that everybody who responded quickly are not reflected, but at some point the responses start being
reflected in the tracking.
I think that the issue is that when some of the responses start coming in, the meeting has not yet been synced to the owners mailbox.  When the reponse comes in, there is no meeting object to update, so it gets ignored. When the calendar oject
finally gets synced the response that come in from that point , are processed and get reflected in the tracking.  this is particularly obvious for meeting rooms, since our rooms are setup to auto-accept and they response within seconds.
I have tried changing the Cache setting, to not cache shared data, this way when the delegate works in the Manager's calender the change are happening directly in the Mailbox.  With this configuration all the meeting response are getting processed.
I can use this workaround for some people but we do have some admins that want to cache the manager's mailbox/Calendar for viewing offline so I also need to find a solution for them.
Thanks
Marc

Answer 1

It is the default behavior, but it also causes many undesired issues.  For instance, consider the following:
If I have a small mailbox, but I have several large shared mailboxes, when I create a profile, those shared mailboxes are added to my OST.  In your estimation, this is all well-and-good.  However, I work for a bank - we have many slow WAN connections
(one for each branch), and a large number of users across these connections.  If you download one large shared mailbox to your workstation, you will swamp the network connection for a very long period (we've had WAN outages caused by shared mailboxes
that lasted most of a day).  Add to this the fact that our tellers do not use the same computer daily, each time they go to a different computer, the cache needs to be totally refreshed.
I have C*Os in this company who have many admins responsible for their Calendar and Inbox.  These admins aren't always able to communicate before scheduling meetings.  Let's consider your situation - the C*O calendar is updated in real time when
changes are made.  Those up-dates are still not replicated real time to the delegates, so even in your best case, they will still not be up to date when they schedule meetings.  (And considering the current operation, they are as much as 15 minutes
behind if they all cache the C*O mailbox.)
We have many shared mailboxes in our organization.  Some of these have many users who have full access.  We have found several issues if these people cache the shared mailbox, such as:
Many times, these users will open an item to work on it, which marks the message as read so others will by-pass it.  We had one group who had six responses to a message because six separate users opened the message and responded.  After all, the
message showed as unread in their cache.
Folders created in the shared mailbox aren't visible to the other users, and may never appear (we've tried forcing folder updates as well as forced replication and nothing causes these new folders to appear).
Users commonly move items to sub-folders within the mailbox.  With cache enabled, we've had ticket opened because one person moved a message to their folder, but someone else moved it to their folder.  Since all were working from cache, the last
cache to update won this contest.
And finally, we have found that while Outlook does a good job of ensuring the cache of the primary mailbox is up-to-date, it doesn't update the shared mailboxes as readily if the workstation is busy, which for our exec admins is most of the time. 
So the cache for the admins of our senior execs (which as I said above are multiple) was rarely updated on a timely basis.  And all of these admins are working on high-speed connections to the server, so it's not a WAN issue in these instances.
Turning off "Download shared folders" fixed all of these issues at the minor expense of taking longer to open items in the secondary mailboxes.