"Operation is not valid due to the current state of the object" when adding additional SID to edsva-MsExch-SharedMailboxUsers

Hi, I am trying to create a workflow to grant users FullAccess to existing shared mailboxes (exchange on-prem) by adding SID to the attribute edsva-MsExch-SharedMailboxUsers but it keeps returning error "Operation is not valid due to the current state of the object" when the WF runs.

If it get it to use Set instead of Add it works fine but Set replaces all the existing users with the new user which I don't want to do, I want the new user to be added alongside the existing FullAccess users

  • $userSid = (Get-QADUser -Identity $SamAccountName).objectSid
    Set-QADUser -Identity $Mailbox-IncludedProperties "edsva-MsExch-SharedMailboxUsers" -objectAttributes @{"edsva-MsExch-SharedMailboxUsers"=@{Append=$userSid}} 

    Also get same error with Set-QADuser:

    Set-QADUser : Administrative Policy returned an error.
    Operation is not valid due to the current state of the object.
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: ***** [Set-QADUser], ObjectAlreadyExistsException
        + FullyQualifiedErrorId : ActiveRoles.ManagementShell.Powershell.Cmdlets.SetUserCmdlet

    Also tried converting SID to base64 as suggested here but still same error

  • The ObjectAlreadyExistsException in the error makes me think edsva-MsExch-SharedMailboxUsers is only meant to be used when creating new shared mailboxes. Maybe it can't be used to add or remove user to existing shared mailboxes even though the GUI has those options:

    (we are on AR version

  • Just in case someone else comes across this issue, the product team have confirmed this is a defect (459239) and are considering a fix in a future release of Active Roles

  • Hello, not directly related to this issue but I have been looking into a similar use case and was wondering if you have seen a difference between adding users like this directly to a shared mailbox vs using group membership? Create the shared mailbox and add a group with FullAccess, then add/remove users to/from the group as needed. Thanks.

  • Hi Richard

    I've not specifically tried it using groups but what I have found is setting permissions using the Set option works fine like when first creating a shared mailbox, the problem I have is when trying to adjust permissions using Add or Remove options on an existing shared mailbox

  • Hi  

    Possibly not related if a defect has been confirmed, but could I ask if your Active Roles Service Account (or managed domain override account, depending on your configuration) is a member of Domain Admins? If not, could you check what object owns the shared mailbox user account?

    This is going back a long time ago (well over 15 years), but I seem to remember after we removed Domain Admins for our service account, we had an issue changing either permissions like you mention above, or some other native ACL. It turned out that because we were neither the object owner, nor a domain admin we couldn't modify the permission/ACL. Normal day to day management of the objects after removing Domain Admins was fine, but the ACL/Permission was not. However all new accounts created via Active Roles after the removal of Domain Admin works fine. We ended up resolving the issue by changing the ownership of the objects we managed to the Active Roles Service Account (or if you use one, the managed domain override account) and then we didn't see the issue. 

    Also the edsva-MsExch-ShareMailboxUsers virtual attribute is defined as below in the SDK

  • Hi Stu

    Our AR service account has Domain Admin