In Microsoft Outlook, when working with Exchange server, you can permit another user to view your calendar, tasks and email items. You can even allow other users to schedule meetings, write emails and create contacts on your behalf. This functionality is known as “delegate access” and has existed Exchange and Outlook for years. The issue I ran into today involved setting up delegate access for a legal secretary. She wants to profile emails for one of the partners at the law firm using the Prolaw XII Outlook add-in. The Prolaw add-in is designed to allow profiling of delegate email messages if delegate access is setup properly.
[the problem]
When a user tries to add a delegate in Outlook 2010 using Exchange 2010, he/she notices the following error:
[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.]
The delegate cannot be added as a result.
Background: When you research the error message shown above, you will most likely stumble upon Microsoft KB article 2593557. This article has instructions on creating registry key (ironically named IgnoreSOBError) that suppresses the above error when adding a delegate. It is misleading in a way because once implemented, users can add delegates without any errors. However, the underlying security issue that caused the error remains unresolved and as such, third party add-ins do not recognize that a delegate has been added or authorized. The KB2593557 fix just suppresses the error message in Outlook and lets you add a delegate without the proper permissions. As a result your third party add-ins do not recognize that a delegate has been added:
[solution]
The instructions below address the security issue in Active Directory and resolve the problem at its root cause rather than ignoring the security error Outlook throws when trying to add a delegate.
[requirements]
- domain administrator account username and password
- basic understanding of Active Directory and AD permissions
- credentials for both the user that wants his email delegated and the delegate user
[step 1] Log into the domain controller open Active Directory Users and Computers. Locate the user account that will be adding a delegate user and open its properties.
[step 2] Click the Security tab and highlight the SELF account. In the list of permissions below, scroll down until you see Read Personal Information and Write Personal Information and place a check into the corresponding Allow check boxes. Click Apply and OK.
[step 3] Log in as the user wanting to delegate email and open Microsoft Outlook. Click File->Account Settings->Delegate Access and add the user that you want the user to delegate access to and specify the appropriate permissions and delegated items. NOTE: If you’ve previously added a delegate using the Microsoft KB article 2593557 fix, you’ll need to remove that delegate and re-add him/her.
Save the delegate settings by clicking OK.
That’s it.
Comments
15 responses to “Delegate settings not saved correctly”
works perfect! thanks
Wow – nailed it! What a great fix, concise and well documented. Thank you!
Thanks a lot. Please note that the settings will revert to defaults and have to be set again if adding or removing delegates. At least on our system.
Didn’t resolve for me. In my case I can’t remove the delegate. I’ve even made the user a member of Domain Admins with no difference. any other ways around this error? The delegate is still getting copies of all calendar requests…
Does the delegate user have full mailbox access to the users mailbox (the one he keeps getting calendar requests for)? If so, you’ll want to remove that first.
I have seen this before where there is a legacy user that is still listed as a delegate. The best way to fix this is to $null the send on behalf for the user in powershell then add back in the delegates as needed.
Set-Mailbox –identity -GrantSendOnBehalfTo $null
There could be a stale jidden rule in Server (A Hidden rule is created to forward meeting invites to delegates) .
Load the profile in MFCMAPI and Delete the stale rule
Thanks for sharing.
While this did not help me it got me on the right track. In my situation, we have 2 domains…. the users (including me) login to DomainA and the mail is still on DomainB. When i opened outlook as the user on DomainA and tried to remove the delegate i received the above error. I had to launch outlook with “run as different user” using the user on DomainB then i could remove the delegates without error.
Thanks for this, worked for me.
@Terry Wilkins: Thanks, this was what caused the problem in our case. Removing a user which had left the company several years ago from de delegates list did the trick.
THANK YOU SO MUCH!!!!! Just wasted an hour trying to fix this, and your website solved it instantly.
Another place to look is direct permissions on the inbox and calendar folders in the local Outlook client. While all of the above ideas helped me, the direct perms ended being the issue for me.
Thank you! Going to the calendar permissions and deleting the users who were delegates from there then allowed me to delete them in the delegates.
In my case it was because of a VPN. I instead logged into an RDS box and opened the mailbox and set the delegate access from there.