Understanding multi-domain DL update and delegate issues after application of Exchange 2003 SP2 - Part 2

Published 01-24-2008 02:52 PM 2,777 Views

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\Preferences
Under 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
Not applicable
I'm laughing at ..."SOB Error" ... because it certainly is one. :)

Will the reg key be automatically created with the necessary value, or does this just make Outlook check for it and it is still up to us to actually enable a value for the key?

We've got 14 domains and 30,000 + users. It will be a bit of a hassel to get the hotfix installed everywhere (although I'm thankful it now exists!). Is there any chance of making Exchange topology discoverer & DSAccess discover/use more than 10 GCs so we can get GCs from all of our domains involved? Right now only about 7 of our domains work properly because numerous GCs from Exchange's domain in its site are first used, then another few from the other domains. We can never get all 14 domains working correctly at any one time because of this. All of the previous workarounds, like you mentioned, typically break something else or cause unacceptable penalties.

Our TAM is in the middle of working on a design change request for us for exactly this issue. Thanks for any insite.
Not applicable
This hotfix just looks for the registry key and does not set it. You have to get it on to the client machines through one of your preferred deployment mechanisms (GPO/Login script, etc..)

As for your other problem, I don't foresee any changes to DSAccess occurring anytime soon as DSAccess will maintain up to 10 In-site GCs and up to 200 out of site GCs. These sites have to be directly connected, not indirectly connected with the Exchange site for you to get referred to one of those out of site GCs and is based on lowest cost.

This is all going to come down to how many domain controllers you have in your environment, site topology, DNS, where your DLs are located, etc. etc..

If you have GC's close to the users in this domain, you could get around this by using the Closest GC registry key. I wrote a blog about how to deploy this key via GPO at http://blogs.technet.com/mikelag/archive/2008/01/09/how-to-update-the-outlook-adm-files-to-add-close... if you are interested.

Not applicable
A quick re-read shows we're responsible for setting the keys.
Not applicable
Mike, we're defintiely not seeing 200 out-of-site GCs being used. E2K3 SP2 is only choosing 10 GCs in total between in-site and out-of-site (with direct site links). This is seen with diagnostic logging cranked up to the max and watching the topology discover happen.
Not applicable
I would suggest opening a case with PSS to get to the bottom of this as something doesn't sound quite right.
Not applicable
Hi Mike,

Case SRX070711600122 was opened on 7/11/2007 about this issue if you would like to review the case notes, 'daveh' was the MSFT Alias I worked with to figure out why things were working they way they were. He reviewed and confirmed our netmon captures during a topology discovery were correct and "working as designed". We were then told 10 GCs was the max; in-site and out-of-site combined.

I would absolutely love to learn 200 is what it really should be and how to fix it. :)

Not applicable
Just FYI: (postign here as I don't see much info or posts on your blog on Entourage & Exchange) ... I think everyone is asking for a comprehensive list of new features in Entourage 2008 and there you go, I just noticed thru a Google search that we have got one here:


Good reading ... I hope it continues ...
Not applicable
Is there somewhere to report bugs?

Trying to restore/merge mailbox info when running a test Dialtone Database I receive an error where it appends the Exchange server's search suffix to the name of the domain controller, rather than using DNS to find it. When starting the mailbox recovery task I specifically selected DC2, so it's extra confusing that this is happening..

Exchange server = Mail.nav.na.domain.com
Domain Controller = dc1.domain.com


Error restoring the mailbox (/O=AAA ORGANIZATION/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=NAME). Error message is: Unable to find 'DC1' computer information in domain controller 'DC1.NAV.NA.DOMAIN.COM' to perform the suitability check. Verify the fully qualified domain name..

Not applicable
Frank: I get the same error. It's very frustrating because I can't see any apparent cause. Did you ever find a solution? Does anyone else have a solution?
Version history
Last update:
‎Jul 01 2019 03:34 PM
Updated by: