locked
Delegating Folder level permissions RRS feed

  • Question

  • Hello,

    I have a doubt, and want to share with you all. I guess I could have any resolution to it.

    Talking about what I want is, we do have an Agenda X Server, collaborated with Exchange 2007 SP3 RU3. The Agenda X service account needs to have custom permissions over lot of mailboxes but from different mailbox databases. Now, the workaround I found is to delegate the permission (only for inbox, and calendar) over user's Mailboxes via PFDAVAdmin tool one by one, which is a very tedious job.

    I am in search of some powershell script/ VB script/ etc. (preferred by Microsoft) to do that in a single go. However I could have proceeded to delegate the permissions on database level which Microsoft have given a shell script, but we cannot apply on database level (due to security reasons). So I ma finding some way other than PFDAVAdmin tool to delegate the permissions on custom folders (user level) but in bulk.

    Can anyone assist me with anything relevant?

    Thanks for all your reverts...  :)

     

    Thursday, September 22, 2011 8:37 AM

Answers

All replies

  • You can use the Exchange Web Services Managed API to script adding delegates to mailbox folders.

    http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=13480

    http://gsexdev.blogspot.com/2009/04/add-delegates-to-mailbox-with.html


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Thursday, September 22, 2011 10:22 AM
  • Hello Mjolinor,

    Thanks friend. I viewed the links you provided and this seems to be a very good tool to use, but I am really not familiar and confident with scripts, may be that's why I am not getting, as how to get this tool worked. I had gone through all the features that this tool provides (http://msdn.microsoft.com/en-us/library/dd633696%28v=exchg.80%29.aspx) ; However, I found the task "Working with delegate access" (http://msdn.microsoft.com/en-us/library/dd633621%28v=exchg.80%29.aspx) relevant to my issue..

    But I am not able to figure out a simple and straight way (steps) to use this tool. Though I went to find how this tool works (http://msdn.microsoft.com/en-us/library/dd633626%28v=exchg.80%29.aspx), which says I have to use Visual Studio and I had never worked upon it.. Can I be able to use it anyways...  :"-(

     

    Friend, can you please assist me with it, as I have a good feeling that this tool may help me out..

    Thanks !!!


    Thursday, September 22, 2011 1:25 PM
  • You do not need to use Visual Studio.

    You can do this with a Powershell script, and the second link I provided has example code in it for doing just that.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Thursday, September 22, 2011 1:33 PM
  • Hello Mjolinor,

    One more question. My requirement is not for delegate permission, rather I need to give reviewer permission to a service account (has no mailbox account attached with it) over inbox and calendar folders of mailboxes. Is this possible. As per my understanding, this tool applies delegate permissions to mailbox account (not service accounts) over mailbox accounts.

    Am I right? Can you focus more over this?


    Thursday, September 22, 2011 2:35 PM
  • You cannot delegate folder level permissions to a non-mailbox enabled account. You'll need to mailbox-enable that service account.
    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Thursday, September 22, 2011 2:50 PM
  • Hello Friends,

    Is there any other way round, as "Exchange Web Services Managed API" is featured for Delegate access through Exchange Web Services, not to grant Folder level permissions to a SERVICE ACCOUNT over Mailboxes.

    Can I have some more comments/ suggestions for the same? Really don't want to use PFDAVAdmin for 500 users one by one.. :-(

    Thursday, September 22, 2011 3:05 PM
  • EWS is just an access method (email client).  It can be used as a scriptable interface to open mailboxes and add delegate permissions to the folders, just as you could do manually using Outlook.

    Once a delegate is added to a folder, it matters not what client is subsequently used by that delegate to access the mailbox folder.

     


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    • Edited by mjolinor Thursday, September 22, 2011 3:21 PM
    Thursday, September 22, 2011 3:14 PM
  • Hello,

    But I found Delegates could be set ONLY for those AD accounts which have Mailbox account too. A Service account does not have a mailbox account. In such a case, could this tool work?

    Thursday, September 22, 2011 5:50 PM
  • NOt that I know of.  You might have better luck in the Development forum:

    http://social.technet.microsoft.com/Forums/en-US/exchangesvrdevelopment/threads

    Delegating permissions to an non mailbox enabled service account is not something an Exchange admin would normally ever need to do.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    • Edited by mjolinor Thursday, September 22, 2011 7:49 PM
    Thursday, September 22, 2011 7:48 PM
  • Friend,

    I found 2 possible workaround for this.

    Option-1

     We use the known PFDAVAdmin tool and set permissions one by one over all the 400 Mailboxes.

     

    Option-2

     We migrate all the said users to two different Mailbox database (200 each), then can perform bulk operations by selecting all the mailbox in a database to set the permission via PFDAVAdmin tool. Then again get the mailboxes migrated to their native stores.

     

    I don't know whether or not Microsoft have any 3rd option or not. I guess not. And as per me this is an Exchange Admin related issue, because though it's a Service account, but the Service account is of Messaging application only. And delegates, and folder permissions are task related to Messaging Admins only.

    However, thanks for your participation friend. But if there's no other option, then Microsoft really should think upon the same to get it developed in forthcomming versions of exchange.

     

    Thanks !!

     

    Friday, September 23, 2011 3:01 AM
  • I understand that it's a service account, but I do not understand the necessity of it not being mailbox enabled in Exchange.  I have other applications messaging applications in my environment that interact with Exchange at the message level, and they use mailbox enabled service accounts. 

    This would have been easily solved by simply mailbox enabling the service account and using EWS to script adding it as a delegate.

    What does your application use to access the message store?  If the service account isn't associated with a mailbox identity in Exchange, then EWS won't work, and it is my understanding that methods like CDO are being de-emphasized in favor of EWS.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Friday, September 23, 2011 10:42 AM
  • Hello,

    I fully agree with you that it could be sorted if I mailbox enable the Service account, but this is not up to me. Of course every one needs to have a solution to a task, not a temporary fix. When if there is no solution with Microsoft to my current structure, I cannot make a organization level change for so. Well, thanks for all your solution. I can just wish to preset your workaround to my organization, but I don't think one would agree to it.

    Thanks anyways.. :)

    Saturday, September 24, 2011 7:34 AM
  • Any solution will need to work within the designed constaints of the application. Operations based on folder level permissions were designed to work off of an Exchnage identity, and Microsoft has stated that going forward, EWS will be the preferred method for programmatic access to mailbox data.

    I can understand there being resistance to wanting to make any change to the organization and wanting to find workarounds to avoid it. 

    You may be able to find a workaround to avoid that service account having an Exchange identity, but you could easily end up with a solution that's going to have to be re-written if you upgrade your Exchange infrastructure because that workaround is no longer supported.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Saturday, September 24, 2011 3:20 PM
  • Hello,

    I didn't understood your words "You may be able to find a workaround to avoid that service account having an Exchange identity, but you could easily end up with a solution that's going to have to be re-written if you upgrade your Exchange infrastructure because that workaround is no longer supported." Are you sugesting to upgrade Exchange version?

    Saturday, September 24, 2011 4:21 PM
  • I am suggesting that the solution you are proposing to make this work in your current (Exchange 2007) environment may not be viable if the organization upgrades to Exchange 2010, or some future version.
    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Saturday, September 24, 2011 4:27 PM
  • Well, according to my current condiguration, when there's no appropriate solution, I am going ahead with below workaround. Could have used definitely Managed API if account would have been Mailbox enabled. :-( 

    • To migrate all users to another empty Mailbox database store.
    • Apply needfull permissions via PFDAVAdmin (over all Mailbox at a time)
    • Then again migrate those Mailbox accounts to their original Mailbox stores.

    I think as this is the easiest way to get things work.

    Thanks friend for your help..  :-)

    Saturday, September 24, 2011 5:29 PM
  • Good luck with it then.

      I wish you no surprises going forward with how this will affect or complicate your mailbox/user maintenance and provisioning procedures, or your organization's ability to upgrade to future versions of Exchange and have the application continue to work.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Saturday, September 24, 2011 6:47 PM
  • We do provide hosted environment i.e. as per our customer's choice. For upgrade, if the customer needs and agrees to the upgraded pros/cons, then we too don't have any problem to do so, but as of now since we have to comply with customer's current need, with no architecture modification, I found my best solution, what I mentioned above with less administrative efforts.

    Thanks !!

    Sunday, September 25, 2011 7:35 AM