EDIT: This post has been updated on 5/20/2008 to include a link to an Outlook 2007 hotfix for this behavior.
If you have been struggling with Delegate errors in multi-domain environments where you consistently get the below error when attempting to add a delegate for a user, you are now in luck as there is a hotfix for Outlook 2003 that will help alleviate some of this pain.
http://msexchangeteam.com/archive/2007/04/09/437620.aspx went in to this in greater detail and some of the pros/cons on some of the workarounds that could have been used to possibly make this work in your environment. The Outlook update to help with this is in the Outlook 2003 post-Service Pack 3 hotfix 946207 and is explained further in 946208. Outlook 2007 version of this fix is referenced in 950794.
To go in to more detail regarding this hotfix, let's touch a bit on why this was previously failing. In a multi-domain environment, it is possible for Outlook to get proxied to a domain controller in which you did not have a writable context to update the users Send on Behalf of list in Active Directory. If this call returned an access denied, the delegate was not added to the user's mailbox and would fail with the above error.
A current workaround would be to pull up Active Directory Users and Computers (ADUC), get properties of the user and then add the Send on behalf of right to the user that is trying to be added to this list. Once Active Directory replication has occurred for this user and the domain controller that Exchange has referred your Outlook client to has this updated information, you could then add the delegate to the user's mailbox successfully. The only problem here is that if you need to add/remove users to the users Delegate list, you have to use ADUC first to add/remove that user from the Send on Behalf of list before they can remove or add delegates again. This is not only a pain, but not an optimal experience for the end user or the administrator that has to add/remove these Send on Behalf of rights.
To make this work 100% in an environment where multi-domains exist, you have to essentially flatten your entire domain structure to a single domain. This way, you don't have to worry about writable contexts to perform these updates on user accounts in Active Directory since there is only one domain to deal with and you will always have a writable context GC. In most environments, this is an unacceptable workaround as these domain security boundaries are needed for clear business needs.
Now, once this Outlook hotfix is applied to the computer, there is a new registry key that is exposed in Outlook called "IgnoreSOBError". The addition of registry key on an Outlook Client will essentially revert the behavior back to the way Outlook used to work before 913696 came out by simply ignoring the inability to update the users Send on Behalf of list, but still allow permissions to be added to the users mailboxes. The only thing that you will not be able to do is to Send on behalf of that user. If you want this ability, you can simply add these permissions in ADUC. A couple of things to mention here is that even without the Send on Behalf of right, you will still be able to send meeting requests on behalf of another user and also accept meetings on their behalf. Anything to do with Calendar items will still work. The only thing that doesn't work without this right is Non-Calendar items, so you will not be able to send a regular mail on behalf of another user. Thanks to Scott Bradley for this added information.
There are 2 places in which you can add this new registry key and are listed below. One is policy based and one can be pushed out through other methods that add entries to the registry on user's computers. These registry keys will apply in order of policy first, user settings, and then the default. The Default is a value of 0.
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Outlook\Preferences HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\PreferencesUnder these keys, you would add a DWORD value of IgnoreSOBError and set it to a value of 1. Once the hotfix is applied and the registry key is added, the next time Outlook is launched, we will read that value in and silently drop the failure to update the users Send on behalf of list. To help track whether a user has this enabled on their machine and we ignored the send on behalf of error when adding a Delegate, we now write an event to the user's computer application log with an Event ID Error of 27. Here is a screenshot of what it would look like:
This essentially gives Outlook the ability to work again in large multi-domain environments without the need of redesigning Active Directory to allow DSProxy to get you to the correct domain controller.
So for anyone that has run in to the problem where Exchange Distribution Lists are in the Exchange domain and all of your user accounts are in other domains and couldn't manage both, then this hotfix is for you. In this type setup, if you are able to get your users to a domain controller in the Exchange domain where your DL's reside and then deploy this hotfix/registry change on all clients, then you will have the best of both worlds where you can manage DL's and have the ability to assign delegates with a side twist of not having the Send on behalf of right by default. This is a small price to pay as most users just want the ability to access another person's Inbox or Calendar items and this hotfix does just that.
- Mike Lagase