Microsoft
Microsoft
\nEDIT 1/24/2008: Please see the Part 2 of this post which has additional information on how to resolve this problem.\nAfter 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. \nThe 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: \n
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.\nTo 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: \n
You do not have the permission to send this message on behalf of the specified user.\nData 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. \nIn 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. \nThis 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. \nMicrosoft 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. \nOk, so now you have configured your Exchange server to refer Outlook clients to the Exchange GC's. This now breaks the ability to assign delegates since the user accounts live in another domain in which we only have a read only partition to make updates against. This of course will get you an access denied every time. \nSo in the end, there is really only one solution to make this work 100% which is moving all of your users and DL's to the same domain which some companies cannot do or cannot afford based on the way that Active Directory was architected in their environment. \nListed below are some workarounds to make certain pieces of this work, but still does not allow everything to work in large multi-domain environments and other solutions needs to be found based on your needs to help address those issues. \n
| \n Possible Workarounds \n | \n\n Pros \n | \n\n Cons \n | \n
| \n For delegate access problems, Assign the \"Write Personal Information\" right to all users or a subset of users in the domain that need the ability to assign delegate rights. \n | \n\n This helps alleviate some of the permissions issues that 913696 introduces \n | \n\n This requires that all users reside in the same Active Directory domain. You can still have multiple domains, but any user that needs the ability to assign delegate rights, those users accounts need to reside in the same domain. Exchange still needs to refer you to a GC with writable context to update the publicDelegates attribute. \n | \n
| \n For DL update issues, Move the distribution groups to the same domain as the user accounts (See 238394 or this for information using MoveTree to move Distribution Groups.) This is the recommended approach to resolve these issues 100% \n | \n\n This allows DSProxy requests to refer you to correct GC to perform the update. Since the DL's and users are all in the same domain, we are able to update DL's and assign delegate permissions. \n | \n\n This requires a good understanding of your AD Site/Subnet topology since the Exchange RFR process now tries to direct you to a user domain GC instead of an Exchange GC based on their current subnet. \n \n\n \n \n Combining both users and DL's in the same domain may break any custom applications that were written exclusively for a particular domain and would have to be changed to accommodate the new location for these groups. \n \n\n \n \n This only works in an environment where there is a single domain to house both the users and DL's. You can have multiple domains, but for this to work correctly, all users and DL's must reside in the same domain and Exchange has to be setup to refer you to the correct GC's as well. This referral mechanism is outside the scope of this document and is better explained in the following links \n \n· http://technet.microsoft.com/en-us/library/b7f8fbf4-732c-4a87-a9d5-3c4c375e5948.aspx \n \n· http://msexchangeteam.com/archive/2005/11/04/413669.aspx \n \n· http://msexchangeteam.com/archive/2006/03/17/422350.aspx \n \n\n \n | \n
| \n Apply hotfix and registry entry of \"RFR Prefer In-Site GCs\" per 912584 to ensure that a GC in the same AD site as the Exchange Server will always be used. \n \n\n \n \n \n | \n\n Allows you to force clients to use GC's within the same AD site as the Exchange Server instead of using User Domain GC's that are not in the same AD site. \n | \n\n If User Domain GC's and Exchange GC's are in the same Active Directory site as the Exchange server, the point system does not change with this registry key being set which is unfortunate. The only way to make this registry key work is to move all User Domain GC's out of the Exchange Active Directory site so that the point system can work and then refer you to Exchange GC's instead of User Domain GC's \n \n\n \n \n This will result in additional load on the GCs in the same Domain and AD Site as your Exchange servers, but this should be minimal. \n \n\n \n \n This will result in issues with delegate permissions that the change to DSPROXY.DLL in SP2 was intended to address if the user accounts are in another domain outside of the Exchange domain. \n | \n
| \n Use a 3rd party tool to provide the ability to update distribution lists via a web interface. See this page for a list of Active Directory partners that may include this functionality. \n \n\n \n | \n\n This allows a single web based interface in to all DL management functions \n | \n\n Microsoft currently does not provide a DL management solution at the current time. \n | \n
| \n Change the details template per this. See Figure 1 below for a sample of what this might look like. \n | \n\n Less intrusive on the client as this change will only need to be changed in one place which is server side. \n | \n\n The details templates would need to be updated for each language. \n \n\n \n \n No workaround still to manage Distribution Lists. Have to purchase 3rd party solution or you can create their own home grown application \n | \n
| \n Per 319206, you can use a GPO to force OL clients to use a specific GC via the \"Closest GC\" and \"DS Server\" registry keys \n | \n\n Temporary fix to workaround issues in certain scenarios where some users may not have the need to perform either a DL Management or Delegate function. You unfortunately cannot have the best of both worlds in multi-domain environments. \n | \n\n The client-detected global catalog server may be out of date or semi-functional. If the global catalog server is having problems but still responds to Named Service Provider Interface (NSPI) requests, Outlook may not stop responding and return to the DSProxy for a new referral. \n \n\n \n \n In multi-domain environments, the global catalog server that you select may not be in the same domain as Active Directory group objects. Therefore, users cannot update group membership because the local global catalog server has a read-only copy of the group. \n \n\n \n \n This key cannot be used in the Exchange Resource Forest Scenario as the GC used by Outlook must be one in the Resource Forest where the mailboxes are located. \n \n\n \n \n Exchange performs a series of suitability tests to make sure a GC is ready/suitable for use by Exchange and its clients; this registry key bypasses that option, which could lead to a bad experience for the client. \n \n\n \n \n If the server goes down that is specified in the DS Server key, Outlook will need to be restarted to connect to another GC. If outlook detects during startup that the specified GC is down, we will go and request a referral to a GC from the Exchange server. \n | \n
| \n Use RPC over HTTP (Outlook Anywhere) for users who manage Distribution Groups. Starting with Exchange 2003 SP1 and later, we no longer enable RFR for HTTP requests, so Exchange is doing all of the proxying to the domain controllers for user requests. This change helped with security issues where GC's were exposed over the internet. \n | \n\n If DL's reside in the same domain in which the Exchange servers live, then the ability to update DL membership might work. This all depends on what DC exchange used to perform the update. \n | \n\n This may work in certain situations, but is not the end all solution as you may get referred to an incorrect GC to perform the DL updates and the configuration of delegates. \n | \n
| \n Use the \"No RFR Service\" registry key per 302914 to disable the RFR interface on the Exchange Server so that we no longer refer you to a GC, but instead, Exchange handles all of the NSPI Proxy requests. If a specific GC is required with this key set, they you can use the \"NSPI Target Server\" registry key to hard code Exchange to use a specific GC to proxy requests to. \n | \n\n This may help alleviate DL update issues if they reside in the same domain as the Exchange server, but can have adverse affects for the ability to update Delegates. \n | \n\n This adds a performance hit on the Exchange servers as the clients have to use the Exchange server for all Address List Lookups instead of offloading this to a GC. \n \n\n \n \n Using this key will require you to recreate all Outlook user profiles as we cache the previously referred GC in the registry of that profile. \n \n\n \n \n Hard Coding an NSPI Target Server will provide undesired results to the client and the Exchange server should that server go down or is unavailable. \n | \n
| \n In a small environment, you can have your Exchange Administrator administer Distribution lists rather than Outlook Users. \n | \n\n Administrators or help desk personnel that have been delegated rights to update group membership can easily update DL membership for their users. \n | \n\n Adds additional overhead for the Exchange or Active Directory Administrator to update DL membership. \n | \n
| \n For delegate scenarios, you can add the Send On Behalf of right on the user account in which you want to delegate permissions to. \n | \n\n This helps alleviate cross domain delegate issues, but you still need to grant specific permissions to the folders once that right is added. \n | \n\n This requires a user to open Active Directory Users and Computers and then grant this right provided they have access to update the user in Active Directory which adds additional overhead. If that user doesn't have permission, then this requires another person with at least account operator permissions to perform this update. \n \n\n \n \n Granting permissions in this way grants no permission by default and requires the user to go back in to Outlook and then grant the appropriate folder permissions for the delegated user. If the user that was granted delegate rights needs to grant someone else delegate access, they need to go through the same steps as above to get this added. \n | \n
![](\"/legacyfs/online/media/themes/exchange/images/437619_MultiDom1.jpg\")
\nRELATED LINKS: \nExchange Server 2003 Service Pack 2 DSProxy Referral Process Changes\nhttp://msexchangeteam.com/archive/2005/11/04/413669.aspx \nExchange 2003 post SP2 DSProxy Referral Update\nhttp://msexchangeteam.com/archive/2006/03/17/422350.aspx \nRELATED ARTICLES: \n318074 \"Do not have sufficient permissions\" error message occurs when you use Outlook Address Book to manage distribution list membership\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;318074 \n921927 How to prevent users from downloading the Offline Address Book without disabling Cached Exchange Mode\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;921927 \n319206 How to configure Outlook to a specific global catalog server or to the closest global catalog server\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;319206 \n912584 The DSProxy service does not direct an Outlook client to the global catalog servers that you want to use in Exchange Server 2003\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;912584 \n912584 The DSProxy service does not direct an Outlook client to the global catalog servers that you want to use in Exchange Server 2003\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;912584 \n924085 Description of the security update for Outlook 2003: January 9, 2007\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;924085 \n238394 How to Use the MoveTree Utility to Move Objects Between Domains in a Single Forest\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;238394 \n913696 Description of the Outlook 2003 post-Service Pack 2 hotfix package: January 23, 2006\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;913696 \nHow to control the DSProxy process for RPC over HTTP connections in Exchange Server 2003 SP1\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;872897 \n- Mike Lagase","kudosSumWeight":0,"postTime":"2007-04-09T15:18:00.000-07:00","images":{"__typename":"AssociatedImageConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"attachments":{"__typename":"AttachmentConnection","pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null},"edges":[]},"tags":{"__typename":"TagConnection","pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null},"edges":[{"__typename":"TagEdge","cursor":"MjUuMXwyLjF8b3wxMHxfTlZffDE","node":{"__typename":"Tag","id":"tag:directory","text":"directory","time":"2018-03-19T11:17:12.944-07:00","lastActivityTime":null,"messagesCount":null,"followersCount":null}},{"__typename":"TagEdge","cursor":"MjUuMXwyLjF8b3wxMHxfTlZffDI","node":{"__typename":"Tag","id":"tag:troubleshooting","text":"troubleshooting","time":"2017-10-05T08:44:04.123-07:00","lastActivityTime":null,"messagesCount":null,"followersCount":null}}]},"timeToRead":12,"rawTeaser":"","introduction":"","coverImage":null,"coverImageProperties":{"__typename":"CoverImageProperties","style":"STANDARD","titlePosition":"BOTTOM","altText":""},"currentRevision":{"__ref":"Revision:revision:594415_2"},"latestVersion":{"__typename":"FriendlyVersion","major":"2","minor":"0"},"metrics":{"__typename":"MessageMetrics","views":8163},"visibilityScope":"PUBLIC","canonicalUrl":null,"seoTitle":null,"seoDescription":null,"placeholder":false,"originalMessageForPlaceholder":null,"contributors":{"__typename":"UserConnection","edges":[]},"nonCoAuthorContributors":{"__typename":"UserConnection","edges":[]},"coAuthors":{"__typename":"UserConnection","edges":[]},"blogMessagePolicies":{"__typename":"BlogMessagePolicies","canDoAuthoringActionsOnBlog":{"__typename":"PolicyResult","failureReason":{"__typename":"FailureReason","message":"error.lithium.policies.blog.action_can_do_authoring_action.accessDenied","key":"error.lithium.policies.blog.action_can_do_authoring_action.accessDenied","args":[]}}},"archivalData":null,"customFields":[],"revisions({\"constraints\":{\"isPublished\":{\"eq\":true}},\"first\":1})":{"__typename":"RevisionConnection","totalCount":2},"body":"\nEDIT 1/24/2008: Please see the Part 2 of this post which has additional information on how to resolve this problem.\nAfter 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. \nThe 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: \n
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.\nTo 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: \n
You do not have the permission to send this message on behalf of the specified user.\nData 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. \nIn 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. \nThis 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. \nMicrosoft 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. \nOk, so now you have configured your Exchange server to refer Outlook clients to the Exchange GC's. This now breaks the ability to assign delegates since the user accounts live in another domain in which we only have a read only partition to make updates against. This of course will get you an access denied every time. \nSo in the end, there is really only one solution to make this work 100% which is moving all of your users and DL's to the same domain which some companies cannot do or cannot afford based on the way that Active Directory was architected in their environment. \nListed below are some workarounds to make certain pieces of this work, but still does not allow everything to work in large multi-domain environments and other solutions needs to be found based on your needs to help address those issues. \n
| \n Possible Workarounds \n | \n\n Pros \n | \n\n Cons \n | \n
| \n For delegate access problems, Assign the \"Write Personal Information\" right to all users or a subset of users in the domain that need the ability to assign delegate rights. \n | \n\n This helps alleviate some of the permissions issues that 913696 introduces \n | \n\n This requires that all users reside in the same Active Directory domain. You can still have multiple domains, but any user that needs the ability to assign delegate rights, those users accounts need to reside in the same domain. Exchange still needs to refer you to a GC with writable context to update the publicDelegates attribute. \n | \n
| \n For DL update issues, Move the distribution groups to the same domain as the user accounts (See 238394 or this for information using MoveTree to move Distribution Groups.) This is the recommended approach to resolve these issues 100% \n | \n\n This allows DSProxy requests to refer you to correct GC to perform the update. Since the DL's and users are all in the same domain, we are able to update DL's and assign delegate permissions. \n | \n\n This requires a good understanding of your AD Site/Subnet topology since the Exchange RFR process now tries to direct you to a user domain GC instead of an Exchange GC based on their current subnet. \n \n\n \n \n Combining both users and DL's in the same domain may break any custom applications that were written exclusively for a particular domain and would have to be changed to accommodate the new location for these groups. \n \n\n \n \n This only works in an environment where there is a single domain to house both the users and DL's. You can have multiple domains, but for this to work correctly, all users and DL's must reside in the same domain and Exchange has to be setup to refer you to the correct GC's as well. This referral mechanism is outside the scope of this document and is better explained in the following links \n \n· http://technet.microsoft.com/en-us/library/b7f8fbf4-732c-4a87-a9d5-3c4c375e5948.aspx \n \n· http://msexchangeteam.com/archive/2005/11/04/413669.aspx \n \n· http://msexchangeteam.com/archive/2006/03/17/422350.aspx \n \n\n \n | \n
| \n Apply hotfix and registry entry of \"RFR Prefer In-Site GCs\" per 912584 to ensure that a GC in the same AD site as the Exchange Server will always be used. \n \n\n \n \n \n | \n\n Allows you to force clients to use GC's within the same AD site as the Exchange Server instead of using User Domain GC's that are not in the same AD site. \n | \n\n If User Domain GC's and Exchange GC's are in the same Active Directory site as the Exchange server, the point system does not change with this registry key being set which is unfortunate. The only way to make this registry key work is to move all User Domain GC's out of the Exchange Active Directory site so that the point system can work and then refer you to Exchange GC's instead of User Domain GC's \n \n\n \n \n This will result in additional load on the GCs in the same Domain and AD Site as your Exchange servers, but this should be minimal. \n \n\n \n \n This will result in issues with delegate permissions that the change to DSPROXY.DLL in SP2 was intended to address if the user accounts are in another domain outside of the Exchange domain. \n | \n
| \n Use a 3rd party tool to provide the ability to update distribution lists via a web interface. See this page for a list of Active Directory partners that may include this functionality. \n \n\n \n | \n\n This allows a single web based interface in to all DL management functions \n | \n\n Microsoft currently does not provide a DL management solution at the current time. \n | \n
| \n Change the details template per this. See Figure 1 below for a sample of what this might look like. \n | \n\n Less intrusive on the client as this change will only need to be changed in one place which is server side. \n | \n\n The details templates would need to be updated for each language. \n \n\n \n \n No workaround still to manage Distribution Lists. Have to purchase 3rd party solution or you can create their own home grown application \n | \n
| \n Per 319206, you can use a GPO to force OL clients to use a specific GC via the \"Closest GC\" and \"DS Server\" registry keys \n | \n\n Temporary fix to workaround issues in certain scenarios where some users may not have the need to perform either a DL Management or Delegate function. You unfortunately cannot have the best of both worlds in multi-domain environments. \n | \n\n The client-detected global catalog server may be out of date or semi-functional. If the global catalog server is having problems but still responds to Named Service Provider Interface (NSPI) requests, Outlook may not stop responding and return to the DSProxy for a new referral. \n \n\n \n \n In multi-domain environments, the global catalog server that you select may not be in the same domain as Active Directory group objects. Therefore, users cannot update group membership because the local global catalog server has a read-only copy of the group. \n \n\n \n \n This key cannot be used in the Exchange Resource Forest Scenario as the GC used by Outlook must be one in the Resource Forest where the mailboxes are located. \n \n\n \n \n Exchange performs a series of suitability tests to make sure a GC is ready/suitable for use by Exchange and its clients; this registry key bypasses that option, which could lead to a bad experience for the client. \n \n\n \n \n If the server goes down that is specified in the DS Server key, Outlook will need to be restarted to connect to another GC. If outlook detects during startup that the specified GC is down, we will go and request a referral to a GC from the Exchange server. \n | \n
| \n Use RPC over HTTP (Outlook Anywhere) for users who manage Distribution Groups. Starting with Exchange 2003 SP1 and later, we no longer enable RFR for HTTP requests, so Exchange is doing all of the proxying to the domain controllers for user requests. This change helped with security issues where GC's were exposed over the internet. \n | \n\n If DL's reside in the same domain in which the Exchange servers live, then the ability to update DL membership might work. This all depends on what DC exchange used to perform the update. \n | \n\n This may work in certain situations, but is not the end all solution as you may get referred to an incorrect GC to perform the DL updates and the configuration of delegates. \n | \n
| \n Use the \"No RFR Service\" registry key per 302914 to disable the RFR interface on the Exchange Server so that we no longer refer you to a GC, but instead, Exchange handles all of the NSPI Proxy requests. If a specific GC is required with this key set, they you can use the \"NSPI Target Server\" registry key to hard code Exchange to use a specific GC to proxy requests to. \n | \n\n This may help alleviate DL update issues if they reside in the same domain as the Exchange server, but can have adverse affects for the ability to update Delegates. \n | \n\n This adds a performance hit on the Exchange servers as the clients have to use the Exchange server for all Address List Lookups instead of offloading this to a GC. \n \n\n \n \n Using this key will require you to recreate all Outlook user profiles as we cache the previously referred GC in the registry of that profile. \n \n\n \n \n Hard Coding an NSPI Target Server will provide undesired results to the client and the Exchange server should that server go down or is unavailable. \n | \n
| \n In a small environment, you can have your Exchange Administrator administer Distribution lists rather than Outlook Users. \n | \n\n Administrators or help desk personnel that have been delegated rights to update group membership can easily update DL membership for their users. \n | \n\n Adds additional overhead for the Exchange or Active Directory Administrator to update DL membership. \n | \n
| \n For delegate scenarios, you can add the Send On Behalf of right on the user account in which you want to delegate permissions to. \n | \n\n This helps alleviate cross domain delegate issues, but you still need to grant specific permissions to the folders once that right is added. \n | \n\n This requires a user to open Active Directory Users and Computers and then grant this right provided they have access to update the user in Active Directory which adds additional overhead. If that user doesn't have permission, then this requires another person with at least account operator permissions to perform this update. \n \n\n \n \n Granting permissions in this way grants no permission by default and requires the user to go back in to Outlook and then grant the appropriate folder permissions for the delegated user. If the user that was granted delegate rights needs to grant someone else delegate access, they need to go through the same steps as above to get this added. \n | \n
![](\"https://techcommunity.microsoft.com/legacyfs/online/media/themes/exchange/images/437619_MultiDom1.jpg\")
\nRELATED LINKS: \nExchange Server 2003 Service Pack 2 DSProxy Referral Process Changes\nhttp://msexchangeteam.com/archive/2005/11/04/413669.aspx \nExchange 2003 post SP2 DSProxy Referral Update\nhttp://msexchangeteam.com/archive/2006/03/17/422350.aspx \nRELATED ARTICLES: \n318074 \"Do not have sufficient permissions\" error message occurs when you use Outlook Address Book to manage distribution list membership\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;318074 \n921927 How to prevent users from downloading the Offline Address Book without disabling Cached Exchange Mode\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;921927 \n319206 How to configure Outlook to a specific global catalog server or to the closest global catalog server\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;319206 \n912584 The DSProxy service does not direct an Outlook client to the global catalog servers that you want to use in Exchange Server 2003\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;912584 \n912584 The DSProxy service does not direct an Outlook client to the global catalog servers that you want to use in Exchange Server 2003\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;912584 \n924085 Description of the security update for Outlook 2003: January 9, 2007\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;924085 \n238394 How to Use the MoveTree Utility to Move Objects Between Domains in a Single Forest\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;238394 \n913696 Description of the Outlook 2003 post-Service Pack 2 hotfix package: January 23, 2006\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;913696 \nHow to control the DSProxy process for RPC over HTTP connections in Exchange Server 2003 SP1\nhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;872897 \n- Mike Lagase"},"Conversation:conversation:594415":{"__typename":"Conversation","id":"conversation:594415","solved":false,"topic":{"__ref":"BlogTopicMessage:message:594415"},"lastPostingActivityTime":"2019-07-01T15:26:54.596-07:00","lastPostTime":"2007-05-03T18:45:28.000-07:00","unreadReplyCount":9,"isSubscribed":false},"ModerationData:moderation_data:594415":{"__typename":"ModerationData","id":"moderation_data:594415","status":"APPROVED","rejectReason":null,"isReportedAbuse":false,"rejectUser":null,"rejectTime":null,"rejectActorType":null},"Revision:revision:594415_2":{"__typename":"Revision","id":"revision:594415_2","lastEditTime":"2019-07-01T15:26:54.596-07:00"},"BlogReplyMessage:message:594416":{"__typename":"BlogReplyMessage","id":"message:594416","conversation":{"__ref":"Conversation:conversation:594415"},"author":{"__ref":"User:user:-1"},"revisionNum":1,"uid":594416,"depth":1,"hasGivenKudo":false,"subscribed":false,"board":{"__ref":"Blog:board:Exchange"},"subject":"Re: Understanding multi-domain DL update and delegate issues after application of Exchange 2003 SP2","readOnly":false,"editFrozen":false,"moderationData":{"__ref":"ModerationData:moderation_data:594416"},"parent":{"__ref":"BlogTopicMessage:message:594415"},"body":"Hello, can you please address an additional issue that does not seem to be mentioned in the workarounds?\n
