After applying SP2 to an Exchange 2003 server, users may have problems updating Distribution list membership and delegating permissions to specific users. This problem is occurring because of a chain of events that occurred after applying specific hotfixes to both the client and the Exchange server.
The first issue was introduced with the application of the Outlook Post SP2 hotfix package in 913696 on the Outlook clients. When this patch is applied, clients could no longer assign delegates, whereas, they used to prior to the hotfix. The user would receive the following error when attempting to add delegate permissions:
The Delegates settings were not saved correctly. Unable to activate send-on-behalf-of list. You do not have sufficient permission to perform this operation on this object.
To elaborate on this a little more, the hotfix package contains an update to address an issue when you attempt to add Delegate permissions for UserB to UserA’s mailbox, we now fail to add these delegate rights if we cannot assign the “Send on Behalf” of right so that the delegate can send mail on behalf of UserA. When assigning delegate permissions based on the above scenario, we actually do two things, we first update the publicDelegates attribute for UserA listing UserB and we then add a rule to UserA’s mailbox for UserB access. This publicDelegates attribute controls the ability to Send on Behalf of that user. The ability to update this attribute for that user requires that the SELF account have at least write access to “Write Personal Information” on the user account that is trying to add the delegate. Prior to this hotfix, if we failed to update publicDelegates, we still added the Delegate Rule in the mailbox to provide limited access to the mailbox. From the end user perspective, they were able to get in to the delegated folder and be able to manipulate items. This “appeared” to the end user that everything was working as expected. Now, if that user attempted to send mail on behalf of that user, they would receive the following error:
You do not have the permission to send this message on behalf of the specified user.
Data in Active Directory is stored in the domain partition and maintained on domain controllers. If you have the appropriate permissions, you can then successfully write to the domain partition. In order to facilitate a global directory, we have to provide that data globally; thus the need for global catalog (GC) servers. Global catalog servers are special domain controllers that hold a writeable copy of the domain partition for their domain, as well as read-only copies of certain data from all other domains within the Active Directory Forest.
In a multi-domain environment, the ability to update the publicDelegates attribute is controlled by whether you can access a writeable copy of the object. This means that we must connect to a GC that is from the same domain as the mailbox-enabled user object is stored, in order for the user to update this attribute. If Exchange referred us to a GC that was not where the user account lived, Outlook would fail to update that attribute and cause the aforementioned delegate error. This delegation error was one of the reasons that Microsoft made a change to the DSProxy referral mechanism in SP2 so that Exchange will now direct you to a domain where you user account lives instead of the domain where the Exchange servers live. This helped alleviate some of the pain points that other customers were seeing and this change helped address those issues. Starting with SP2, Exchange now uses a point system that uses a constraint algorithm to determine the best suitable domain controller that is sent back to the Outlook user. This new algorithm is discussed in http://technet.microsoft.com/en-us/library/b7f8fbf4-732c-4a87-a9d5-3c4c375e5948.aspx.
This unfortunately had a negative impact to update DL membership when the DL’s were housed in the Exchange domain, thus causing the inability to update DL membership from an Outlook client. This occurs because Exchange is now referring you to a domain where your user account lives instead of the Exchange domain. You basically had a 50/50 shot that this was going to work depending on what domain controller Exchange refers you to. Exchanges preference once SP2 is applied is a user domain GC instead of an Exchange domain GC.
Microsoft then came out with a Post SP2 hotfix (912584) that adds a new registry key of “RFR Prefer In-Site GCs” to help ensure that a GC in the same AD site as the Exchange Server will always be used. That doesn’t guarantee that it will be a GC from the same domain as the Exchange sever. UserGCs first, then any other GC sorted by point cost.. If you had Exchange and user domain GCs in the same Active Directory site, then this new registry change does not make any difference with the point system and will still refer you to a user domain GC as a first preference. To resolve this behavior so that the point system works, you would need to move the user domain GCs out of the Exchange Active Directory site, thus leaving only the Exchange GCs in site where Exchange lives. Once this is done, the point system will work in a way that we will now prefer Exchange domain GC’s instead of user domain GC’s. This mimics the behavior prior to SP2 of Exchange.
View: Full post
Microsoft, Exchange, Multi-domain, DL, Update, Exchange 2003, Service Pack, SP, Directory, Troubleshooting, Tips, Tricks