Let’s say we have a user called User-A. User-A delegated his/her calendar to User-B. User-B has full authority to accept/decline meeting requests on behalf of User-A. Now, another user User-C sent a SharePoint Workspace Meeting Request to User-A. If User-A accepts/rejects this request by himself/herself, it will reflect in the SharePoint Workspace. But if User-B does the same on User-A’s behalf, it does not change the status in the SharePoint Workspace.
What I found after investigation is:
- When a SharePoint Workspace Meeting is initiated by a presenter, it creates a meeting workspace site under given URL and adds presenter with “Full Control” access and attendees with “Contribute” access.
- When an attendee (or a delegate) accepts or decline a SharePoint Workspace meeting from outlook, a web service call to “/_vti_bin/meetings.aspx” of the Workspace site is initiated from outlook. This call does not routed through Exchange.
- When this web service call initiated, outlook sends the credential of the current user to SharePoint. If the user has “Contribute” access to the SharePoint site, it will successfully update the meeting acceptance.
- Essentially a delegate, as he has no access to the SharePoint site cannot change the acceptance status although he has full access to attendee’s calendar.
Let’s look into it step by step:
We have used 3 servers (VMs) with latest software for the PoC with following config:
- Server1: Windows Server 2008 R2, Exchange 2010, Office 2010
- Server 2: Windows Server 2008 R2, SharePoint 2010, Office 2010
- Server 3: Windows Server 2008 R2, SQL 2008 R2, Office 2010
User (Administrator) starts a SharePoint workspace meeting and invites User (pranabp).
Once invitation is sent we can go and see the permissions available in the target meeting workspace site.
The user (pranabp) has delegated the calendar to user (arthuro) and “arthuro” can accept/decline meeting request on behalf of “pranabp”.
Let’s look at the fiddler trace during the meeting acceptance of “arthuro” on behalf of “pranabp”. As we can see outlook process is directly calling SharePoint web service. Also the call is failing because of permission issue.
Also if we see the outcome in the SharePoint “Attendees” list, we can see the Response field is not updated.
Now let’s create another workspace and this time we will add “arthuro” as contributor in the workspace site manually once it is created.
We will continue and again accept the meeting from the calendar of “arthuro” on behalf of “pranabp”.
Let’s look at the fiddler trace now. It’s a success. Also the SharePoint “Attendee” list shows accepted by user “pranabp”.
So, in the conclusion we can say, we need to have the delegated users as contributors to the SharePoint Workspace site. As you can see, it’s highly improbable that the user who is inviting other users for a meeting will have much understating about their calendar delegation.
Well, we do not have any straight-forward solution for this situation. There can be multiple workarounds – let’s hope someone the reader community of this blog post can point out such an workaround.