none
GetDelegate does not find the user RRS feed

  • Question

  • I use the GetDelegate web service as I want to know the delegate permissions of an user.

    The problem is that the response is ErrorItemNotFound if i call the service on our production server as soon as i check on a different user than my own.

    On our test servers the service call succeeds, and if i call it for a non-existing user i get ErrorNonExistentMailbox.

    The test servers are 2007SP1 and 2010SP2, production is 2010SP2.

    Is there maybe a server setting we have set incorrectly?

    As a workaround i will try to retrieve the Item_Effective_Rights field on all retrieved elements, but having the DelegatePermissionLevel items would make it much easier to manage the permissions.

    Any ideas?

    Tuesday, December 10, 2013 10:02 AM

Answers

  • EWS should honour the Private flag (as long as the user isn't getting additional rights from the Mailbox DACL). You need to check your server versions this was a bug that was fixed in a Exchange 2010 rollup http://support.microsoft.com/kb/2783649

    >>Is there a way other than the GetDelegate operation to retrieve the "can view private items" permissions of a delegate user?

    I don't believe so

    Cheers
    Glen 

    • Marked as answer by Simon Hain Thursday, December 12, 2013 6:20 AM
    Thursday, December 12, 2013 2:02 AM

All replies

  • Hi

    You can look at Pauls thread regarding viewing permissions:

    http://exchangeserverpro.com/list-users-access-exchange-mailboxes/

     get-mailboxpermisson -identity <user> |fl.

    Tuesday, December 10, 2013 11:39 AM
    Moderator
  • unfortunately i don't have access to the powershell from my target device, i am using EWS in a mobile context.

    My issue is not that i cannot find out the permissions in any way, i cannot retrieve them using Exchange Web Services GetDelegate method specifically.

    It seems that there must be a setting on the Exchange that results in the web service replying with ErrorItemNotFound. I can use delegate access to folders or items without issue, it is only the GetDelegate service that is not working.

    Tuesday, December 10, 2013 12:05 PM
  • The Delegate operations in EWS are meant to be used by the Mailbox Owner (or someone with equivalent permission) to managed the delegates on a Mailbox. The reason it works on your test server is that most probably you are using an account that has FullAccess to all mailboxes. In a production environment you generally won't find the same rights.

    If your using a Service Account you might want to consider using EWS Impersonation which will let you impersonate the owner of the mailbox see http://msdn.microsoft.com/en-us/library/bb204095(EXCHG.140).aspx 

    Cheers
    Glen

    Wednesday, December 11, 2013 5:56 AM
  • Ok, i was not aware of this limitation. I am pretty sure that the accounts on our test server do not have full access to eachother, but as i don't know about the internal workings i trust you on that.

    I have refactored my code to handle most permissions, but the one thing that eludes me now is the permission to view private items. On the GetDelegate response there is a boolean flag, ViewPrivateItems, for that if i set IncludePermissions to true.

    I have created a private appointment and when i access it with FindItem and the delegate user i get Sensitivity "Private", but the Read flag in EffectiveRights is "true", despite the delegate not being allowed to view private items.

    Is there a way other than the GetDelegate operation to retrieve the "can view private items" permissions of a delegate user?

    Wednesday, December 11, 2013 9:19 AM
  • EWS should honour the Private flag (as long as the user isn't getting additional rights from the Mailbox DACL). You need to check your server versions this was a bug that was fixed in a Exchange 2010 rollup http://support.microsoft.com/kb/2783649

    >>Is there a way other than the GetDelegate operation to retrieve the "can view private items" permissions of a delegate user?

    I don't believe so

    Cheers
    Glen 

    • Marked as answer by Simon Hain Thursday, December 12, 2013 6:20 AM
    Thursday, December 12, 2013 2:02 AM
  • As our base version is Exchange 2007SP1 that means that we have to hide all private appointments by default, i guess.
    Maybe we can put in a version check to have a different behavior on a 2010 exchange, we'll test the behavior there.

    Thank you for your insights!

    Thursday, December 12, 2013 6:20 AM