none
Change in behavior for delegate creation of meetings RRS feed

  • Question

  • We have EAs who have full mailbox access to their VPs and managed their calendars as secondary mailboxes, and are migrating from Exchange 2003 to Exchange 2010sp1ru2. 

    If an EA was granted mailbox access after migration, and creates a meeting appointment in a VP mailbox, The VP gets a meeting forward notification at the time of creation. 

    If, however, the EA-VP relationship has carried over from our Exchange 2010 environment, the same behavior (creating a meeting) does not generate a meeting forward notification.  Meeting forward notifications only occur when a meeting is generally forwarded (and not when it is created).

    Have other people encountered this behavior?  Does anyone know why the same permissions generate two different sets of behavior based upon when the permission was granted?  Is there a way to speecify one behavior over the other?

    Thanks,

    Gordon

    Wednesday, June 22, 2011 6:09 PM

Answers

  • Well, in Exchange 2010, the notification should not be generated when the delegate user creates a new meeting request for VP, it is the same as it is in Exchange 2003.

    I am suspecting that your VP's mailbox was a "Direct booking" resource mailbox in Exchange 2003 and it was not be correctly migrated. So, it is worth to verify and undo the VP's mailbox permission settings. for more information, see http://technet.microsoft.com/en-us/library/bb232195(EXCHG.80).aspx.

    -Fiona

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Thursday, June 30, 2011 6:01 AM
    Moderator

All replies

  • Hi Gordon,

     

    The Calendar processer changed from Exchange 2003 to Exchange 2007, and also, the permission level on calendar folder has been extended. So a migrated shared mailbox might appear to be strange.

     

    For the issue you are encountering, I would suggest you remove the problematic delegate, undo the calendar sharing for the affected VP, and then add the delegate again via Outlook option.

     

    Hope it is useful.

     

    Best regards,

    Fiona Liao


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Friday, June 24, 2011 1:46 AM
    Moderator
  • The thing is, our VPs like the way the permissions were handled coming in from 2003 into Exchange 2010, where their EAs would create an appointment and they would not see the forward, but if a recipient then forwarded it on, they got the notification.    What changes between those legacy permissions in 2010, and new full mailbox permissions as they are granted in 2010 that makes that intellegent forwarding  (i.e. forward notification on forward, no forward notification on create) no longer possible?

     

    Thanks,

    Gordon

    Tuesday, June 28, 2011 6:57 PM
  • Well, in Exchange 2010, the notification should not be generated when the delegate user creates a new meeting request for VP, it is the same as it is in Exchange 2003.

    I am suspecting that your VP's mailbox was a "Direct booking" resource mailbox in Exchange 2003 and it was not be correctly migrated. So, it is worth to verify and undo the VP's mailbox permission settings. for more information, see http://technet.microsoft.com/en-us/library/bb232195(EXCHG.80).aspx.

    -Fiona

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Thursday, June 30, 2011 6:01 AM
    Moderator
  • The VP mailbox is a traditional mailbox.  We have not used resource mailboxes in our organization.  It is useful to know that the behavior we are seeing is not what would be expected.  We'll do some additional tests and open a premier ticket if needed.
    Tuesday, July 19, 2011 12:19 PM