Solving "The Delegates settings were not saved correctly" Error on Exchange 2010
Article by Danijel Klaric, Premier Field Engineer.
One of my customers came to me with the following issue and asked if there were “better” solutions available than they found using their own Internet research. They use a mix of Outlook 2007 and Outlook 2010 clients and a lot of shared mailboxes. The access to these mailboxes is granted through group memberships, which have “full mailbox access” and “send-as” permissions granted. Outlook is configured to use a second profile for the Shared Mailbox access.
The Symptom:
In the phase of testing their mailbox migration to Exchange 2010 Sp1 RU6 they encountered the following issue trying to delegate Calendar permissions using the “Outlook delegation wizard” on their shared mailboxes:
“The Delegates settings were not saved correctly. Cannot activate send-on-behalf-of-list. You do not have sufficient permission to perform this operation on this object”
Troubleshooting steps:
If you do an Internet research there appear to lots of people complaining about this exact behaviour. The two most popular described solutions are the following:
1. Using the “IgnoreSOBError” – “SendOnBehalf” Registry key to silently drop the error message and proceed with permission assignment. With the usage of this key the described error message is just dropped by Outlook and the selected permissions out of the delegation wizard are applied (without setting the SendOnBehalfof permission).
The SendOnBehalf Permission is not needed to act as calendar delegate. If the delegate has to use the “send on behalf of” permission for writing email “in behalf of” this has to be done by an administrator using the Exchange Management Shell or Exchange Management Console.
Outlook 2007 Registry key:
HKCU\Software\Microsoft\Office\12.0\Outlook\Preferences or
HKCU\Software\Policies\Microsoft\Office\12.0\Outlook\Preferences
Dword: IgnoreSOBError value = 1
Outlook 2010 Registry key:
HKCU\Software\Microsoft\Office\14.0\Outlook\Preferences or
HKCU\Software\Policies\Microsoft\Office\14.0\Outlook\Preferences
Dword: IgnoreSOBError value = 1
2. Create a new RBAC role and strip all parameters for “GrantSendOnBehalf plus Identity” and add the user who should be able to do their delegation without an error. In this case the Outlook Wizard will finish successfully and the delegate will be added to the list of “publicDelegates”.
The downside of this solution about using this “Organization wide” RBAC role is that the user is now able (using remote PowerShell) to “GrantSendOnBehalf” in every mailbox, not only his delegated mailboxes.
So what’s happening?
My customer didn’t like either workaround. Since Exchange 2010 Sp1 RU6 we are able to provide a solution without any downside and/or negative impact as described in solution 1 or 2.
The Sp1 RU6 update introduced two things:a new RBAC role called MyMailboxDelegation, and a new implicit RBAC scope which is called MailboxICanDelegate.
These two things combined enable us to delegate exactly what we need:
- Manage the grantSendonBehalf permission
- Ensure that this can only be done on mailboxes the user is delegated of – new Scope MailboxICanDelegate
Check this out using “(Get-ManagementRole MyMailboxDelegation).RoleEntries | fl Name,Parameters” and “Get-ManagementRole MyMailboxDelegation | fl name,ImplicitRecipientWriteScope”
How Did We Solve It?
Ensure that at least Exchange 2010 Sp1 RU6 or Exchange 2010 Sp2 is deployed in your environment. With this deployed you are able to use the new RBAC role by using the following:
First, the new RBAC role must be assigned to the “User with full mailbox access” and, second, this user has to be granted additional Active Directory permission.
Please note: Every Exchange 2010 Mailbox has an associated “user role assignment policy.” In most cases this is the default one called "Default Role Assignment Policy." If you have changed this in your environment, ensure that you make the assignment to the right policy.
Let´s start with Exchange 2010 Sp1 RU6 environments:
If you are still using Exchange 2010 Sp1 RU6 one preparation step is needed beforehand. Ensure that you are member of the “Organization Management” group. Open Windows PowerShell on one of your Exchange Server 2010 consoles and execute the following three commands, afterwards follow the same path as described for SP2. This will enable the “Organization Management” Role Group members to configure the new role “MyMailboxDelegation.“
[PS]C:\>Add-PSSnapin microsoft.exchange.management.powershell.setup -ErrorAction silentlycontinue
[PS] C:\>Install-CannedRbacRoles
[PS] C:\>Install-CannedRbacRoleAssignments
If you already upgraded to SP2 or just started your deployment with SP2 then start here:
Ensure that you are member of the “Organization Management” group to accomplish the tasks:
1. Check if the new role is delegated to the Organization Management Role group for further configuration
“Get-ManagementRoleAssignment -Role MyMailboxDelegation | fl name,RoleAssignmentDelegationType”
Check if the assignment is there and the type is “DelegatingOrgWide”:
2. If the “delegation” assignment is available go further with the step of assigning it to your appropriate “Role Assignment Policy”:
[PS] C:\> New-ManagementRoleAssignment -Name ‘Mymailboxdelegation-Default Role Assignment policy’ -Role "Mymailboxdelegation" -Policy "Default Role Assignment Policy"
3. Now the mailbox manager must be granted Active Directory permissions to write “Personal-Information”, so that the “publicDelegate” attribute could be changed:
[PS] C:\>Add-ADPermission "Delegated Mailbox" -User “UserwithFullMailboxAccess” -AccessRights WriteProperty -Properties Personal-Information
4. After these steps, the delegate should be able to configure the calendar delegation with “SendonBehalf” using the Outlook Delegation Wizard without the error message.
That’s all…thanks for reading...hope this was helpful.
Further helpful links on the topic: