Exchange 2003 post SP2 DSProxy Referral Update


In November 2005 I posted an article on the DSProxy referral changes that are included in Exchange Server 2003 Service Pack 2.  For the full article, please see http://blogs.technet.com/exchange/archive/2005/11/04/413669.aspx.


 


To refresh everyone's mind, prior to Exchange 2003 Service Pack 2, a DSProxy Referral would provide the Outlook client with a global catalog server from one of two locations:


1.            The global catalog is located within the same AD site as the Exchange server (normal behavior).


2.            The global catalog is located within an AD site that is directly connected to the Exchange server's AD site (when all in-site GCs are unavailable).


 


In addition to honoring site membership, DSProxy prefers to use global catalog servers that are members of the same domain as the Exchange server.  If none are available, then DSProxy will utilize the other global catalog servers in the AD site.


 


This poses a few issues in multi-domain environments where DomainPrep has been executed against the domains.  Specifically, if an Outlook client is referred to a global catalog server that does not reside in the same domain as the mailbox-enabled user, then that user will be accessing data that is in a read-only fashion.  This means that updates to certain objects (whether it be updates to the mailbox-enabled user like delegate access, or distribution group membership) may fail.


 


In Exchange 2003 SP2, the referral process will now attempt to provide the Outlook client with a GC that belongs to the same domain as the mailbox-enabled user using a new algorithm.  The new algorithm will solve the delegation issue, provided a global catalog server exists and is reachable by the Exchange server for the mail recipient.  It may address the distribution group issue if the distribution group resides in the same domain as the mailbox (otherwise it won't because the GC only contains a read-only copy of the distribution group).


 


Recall that with SP2, we score the desirability of a global catalog based several constraints:


1.            A GC that is available (RPC ping) - 16 points


2.            A GC that supports the Clients protocol - 8 points


3.            A GC belonging to the users domain - 4 points


4.            A GC within the same AD site as the Exchange Server - 2 points


5.            A GC that is one of the GCs that the Exchange Server is currently using - 1 point


 


With this model, a client could be referred a global catalog that does not belong in the AD Site of the Exchange server due to the global catalog's domain membership matching that of the mailbox-enabled user.


 


The new referral mechanism may not be advantageous if:



  • You deployed distribution groups in a centralized domain and placed GCs of that domain in the Exchange Server's AD site to allow for membership updates to occur through Outlook.  
  • You did not deploy mailbox home-domain GCs in the Exchange Server's AD site.


Post-SP2 DSProxy Referral Mechanism Update


The good news is that the DSProxy Referral behavior can be altered to so that you can simulate Pre-SP2 behavior.  In order to do that you must install KB 912584, which provides a Post-SP2 version of DSProxy.dll.  This fix allows for the use of the following registry key:


 


Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\MSExchangeSA\Parameters


REG_DWORD Value: RFR Prefer In-Site GCs


Data: 0 (Disabled, default behavior)


Data: 1 (Enabled)


 


With this registry key set to a value of 1, the constraint cost will change and utilize the following model:


 


1.            A GC that is available (RPC ping) - 16 points


2.            A GC that supports the Clients protocol - 8 points


3.            A GC belonging to the users domain - 1 point


4.            A GC within the same AD site as the Exchange Server - 2 points


5.            A GC that is one of the GCs that the Exchange Server is currently using - 4 points


 


So if we go back to the SP2 example I provided in the original blog post, enabling this registry key will alter the way in which the DSProxy service assigns points to the global catalog servers:


 










































































































Server


Active Directory Site


In-Use by DSAccess?


Constraint


Total Points


1


2


3


4


5


ExDomain GC1


Exchange AD Site


Yes


16


8


0


2


4


16+8+2+4=30


ExDomain GC2


Exchange AD Site


Yes


16


8


0


2


4


16+8+2+4=30


UserDomain GC1


Client AD Site


No


16


8


1


0


0


16+8+1=25


UserDomain GC2


Client AD Site


No


16


8


1


0


0


16+8+1=25


UserDomain GC3


AD Site B


No


16


8


1


0


0


16+8+1=25


UserDomain GC4


AD Site B


No


16


8


1


0


0


16+8+1=25


ExDomain GC4


AD Site A


No


16


8


0


0


0


16+8=24


ExDomain GC5


AD Site B


No


16


8


0


0


0


16+8=24


ExDomain GC6


AD Site B


No


16


8


0


0


0


16+8=24


 


The net effect of this change is that global catalog servers that are currently being utilized by the Exchange server will be preferred by the DSProxy Referral service. 


 


Please note that even with this registry change, DSProxy can still refer clients to a global catalog server that is in use by the Exchange server and that is a member of the same domain as the mailbox-enabled user due to the constraint cost assignment.  Consider the following scenario:


 




 


In this scenario, the global catalog servers will be assigned the following points by the DSProxy service (assuming the registry key is enabled):


 


































































Server


Active Directory Site


In-Use by DSAccess?


Constraint


Total Points


1


2


3


4


5


UserDomain GC1


Exchange AD Site


Yes


16


8


1


2


4


16+8+1+2+4=31


ThirdDomain GC1


Exchange AD Site


Yes


16


8


0


2


4


16+8+2+4=30


ThirdDomain GC2


Exchange AD Site


Yes


16


8


0


2


4


16+8+2+4=30


UserDomain GC2


Client AD Site


No


16


8


1


0


0


16+8+1=25


UserDomain GC3


Client AD Site


No


16


8


1


0


0


16+8+1=25


 


In this particular example, Exchange will provide the UserDomain GC1 server that is in-use by Exchange to the Outlook clients due to that global catalog server having a higher point calculation than the ThirdDomain GC1 or GC2 servers.  If UserDomain GC1 were to become unavailable, DSProxy would utilize the ThirdDomain GC1 and GC2 servers before referring clients out of the Exchange AD site.


 


So to summarize, enabling the "RFR Prefer In-Site GCs" registry key:



  • Prioritizes GCs that are being used by Exchange over home domain membership.
  • GCs that are both being utilized and are members of the same domain as the mailbox-enabled user will be preferred over non-home domain GCs.
  • DSProxy will only refer clients out of site if all GCs within the Exchange server's AD site are unavailable.  Constraint assignment will determine which GCs are utilized by the DSProxy Referral Process.


Please contact Microsoft Support to obtain fix KB 912584 if you would like to deploy the updated DSProxy Referral mechanism (the article itself is still being written).


 


- Ross Smith IV

Comments (18)
  1. Anonymous says:

    Microsoft renames ActiveSync to Windows Mobile Device Center

    Life Without Exchange

    Microsoft’s Exchange…

  2. Joe says:

    Good post Ross, I enjoyed it.

  3. Thomas K.H. Bittner says:

    I’m still wondering, if you can rely on, that the Exchange Server, which has no GC of the user’s domain in his site, will also provide the client with the GC of his domain, even if the GC is not in the ‘Top 10’ of the Exchange Server’s DSACCESS discovered list shown in event id 2080.

    Will an Exchange server use a GC of the user’s domain, which is in it’s incarnation list, and give it points or not? Or will it pass another GC (of anonther domain than the user’s domain) of the Exchange site to the client?

    Cause we can not see the clients getting their GC after SP2.

  4. Hi Thomas,

    From your description it sounds like you have an Exchange AD site that contains GCs that are NOT in the same domain as the mailbox-enabled users.  If there are any home-domain GCs in AD sites that are directly connected to the Exchange server’s AD site, then DSProxy will refer the mailbox-enabled user’s Outlook client to one of those GCs.

    If you have no home-domain GCs in any directly connected AD site of the Exchange server or within the Exchange Server’s AD site, then DSProxy cannot refer the Outlook client to a GC of the same domain as the mailbox-enabled user.

    DSAccess’ incarnation list will only contain 10 AD servers in-site, or 10 AD-Servers out-of-site if all in-site servers are down.  But DSProxy has a list of ALL AD servers in ALL directly conencted sites and only uses membership in the incarnation to assign points to servers.

    Ross

  5. Anonymous says:

    Here is some recommended reading.  Ross Smith IV has made another post about the changes in DSProxy…

  6. EngineerBoy says:

    What appears to be left unspoken in all of this is that the actual math should be that a GC in the client’s site in the client’s domain should be the preferred referral GC.

    Any chance that E12 and the new version of Outlook add these factors to the equation?

  7. EngineerBoy,

    We are looking at how we can improve the referral process for Exchange 12.

    Ross

  8. Adolfo Guzman says:

    By default, Outlook 2002 requests a global catalog referral from DSProxy. This strategy works well in many scenarios. Under some circumstances, however, you may want to configure the client to use a specific global catalog server. For example, the Outlook client and the Exchange server may be separated by a WAN (Figure 7).

    Figure 7   WAN separating Outlook and Exchange server

    In Figure 7, the Exchange 2000 topology is centralized with all Exchange 2000 servers located at the data center of the company. Users are located in branch offices, and log on to their mailboxes over the WAN. By default, Outlook receives a referral to either GC1 or GC2. This is because DSProxy identifies the global catalog servers that are closest to the

    server running DSProxy, rather than the global catalog servers that are closest to the client. In this example, the Active Directory designers have chosen to implement a global catalog server at the branch office so that logon traffic is kept local.

    Although the default referral works, you can optimize traffic patterns by configuring the following registry key so that the client uses the closest global catalog server.

    Location

    HKEY_CURRENT_USERSoftwareMicrosoftExchange

    Exchange Provider

    Name

    closest GC

    Type

    REG_DWORD

    Value

    0x00000001

    In other topologies, you may want to force Outlook to communicate with a specific global catalog server. Although you can manually change the registry parameter in the MAPI profile, it will be overridden the next time the client computer starts. To force Outlook 2002 to use a predefined global catalog and override settings in the MAPI profile, set the following special registry key.

    Location

    HKEY_CURRENT_USERSoftwareMicrosoftExchange

    Exchange Provider

    Name

    DS Server

    Type

    REG_SZ (string)

    Value

    <FQDN of the global catalog server>

    With either of the previous registry settings, if the specified global catalog server fails, Outlook will request a new referral from DSProxy. When configuring the client to select the global catalog server, you should remember the following:

    ·    The global catalog server chosen by the client may be out of date or may not be fully functional. If the global catalog server is having problems but still responds to NSPI requests, Outlook may not fail over to DSProxy for a new referral.

    ·    In multiple-domain environments, the global catalog server chosen by the client may not be in the same domain as Active Directory group objects. Therefore, users may not be able to update group membership, because the local global catalog server has a read-only copy of the group.

  9. jens says:

    Hi Ross,

    I refer to your post from March 20, 2006 12:23 PM where you were talking about GCs in directly connected sites. We tried to verify that. In an AD site topology where site A, B and C have site links to each other but one of the link between A and C has costs of 1000 (the others have 1) we noticed that if the users home domain is in Site A and the Exchange server (member of another domain) is in Site C the client always gets a GC from site C. If the exchange server ist in site B everything works fine.

    So how do site link costs affect the points a GC is awarded during DSProxy referral process?

  10. Regarding Adolfo’s comments:

    1.  ‘Closest GC’ only works with Outlook 2002 and later.

    2.  ‘DS Server’ works with Outlook 2000 and later.

    This is documented in http://support.microsoft.com/kb/319206/en-us

  11. Jens,

    So site link information only has bearing on DsProxy’s GC selection algorithm in the “in-incarnation” part of the points calculation.  In other words, site link cost comes into play with DSAccess topology generation (e.g. the 10 in-site GCs).  The DSProxy referral mechanism will assign point(s) for in-carnation but depending on the behavior (default SP2 or the information I discussed in this blog), the user may be redirected out of site to a home-domain GC.

    Ross

  12. Tom Mock says:

    We are having a problem where after the SP2 being applied, SOME, but not all of our Outlook clients are getting logon popups from a GC in another domain in our forest. If the user either enters their credentials, or just exits out of the popup things seem to be ok.

    The easiest way for me to replicate the problem is to create a new outlook 2003 profile, and click check names. The popup will always occur. This didn’t happen before the Sp2 application. We have used RPCPING from the resource kit (although I only used the -s flag and specified the GC in our domain) and rpcpings were replied too. So why then are we being refered to a GC outside our domain? All others GC’s are in other domains, and therefore my domains GC should win the DSACCESS algorithm. All GC’s in the forest are in 1 site. Any ideas?

  13. Kevin says:

    Hi Ross

    For most circumstance, you want Exchange to refer a GC that is local to the Outlook clients to prevent traffic going across the WAN and that is why the referal process is changed to the way it is in SP2. Is this correct?

    If this is correct, we will still need to employ the closestGC registry value so remote clients will point to their GCs assuming we are in a single domain environment. Judging from your article, it really makes no difference if all users belong to the same domain as the Exchange servers. Exchange will continue to use GCs that are closeest to them.

    Kevin

  14. Hi Kevin,

    No your first statement is not correct.  Prior to Exchange 2003 SP2, DSProxy would refer clients to global catalogs that were in the same AD site as the Exchange server, as well as, prefer GCs that were in the same domain as the Exchange server.

    In Exchange 2003 SP2, we altered the algorithm so that we would attempt to provide the Outlook client with a GC that matched the same domain as the mailbox-enabled user.  However, this has no bearing on the Outlook client’s location in terms of AD Sites and Services, we still utilize DSAccess to determine the GC list and DSAccess builds its topology based on the Exchange server’s AD site and those directly connected to it.

    The Closest GC registry key that is available in Outlook 2002 and later is so that you can configure your clients to use GCs that are within their AD site, as opposed to, using the GCs that DSProxy is providing that are in or near the Exchange server’s AD site.  However, there are a few problems with Closest GC that are worth mentioning:

    1.  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.

    2.  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.

    Ross

  15. Hi Tom,

    I would suggest opening a support case with Microsoft Services, as it sounds like you have authentication issues within your Active Directory forest.

    Ross

  16. Marc C says:

    I posted something a while ago “We actually prefer the old algorithm, when we migrated to Exchange 2003 we planned ahead and put all the DLs in the same site of our Exchange servers (they are all in the same domain), users are scattered across 5 other domain. This way the DL update issue is negated, as for the delegate problem we had no way to design around it. Now we are swapping problems. Any chance that we can at least control the algorithm? BTW: Why don’t you guys get together with the Office team and fix the problem for real, this is a know problem since 1999, there is no reason other than motivation for this problem to exist?.”

    Your response was “Stay tuned…I will be posting an update in the Dec/Jan timeframe that answers your issue. “

    If you were talking about the “RFR Prefer In-Site GCs” it doesn’t do anything to help us since we have overlapping Domains in the same site.  So even with this switch our client’s still get “permission denied” Popups when trying to modify DL that they in fact have permissions for.  The only alternative that was given to us with KB 912584 is to created a dedicated site for Exchange and our ExDomain GCs.

    Alternatively, we are looking into using the “NO RFR Service” switch and having all DS requests proxied by the Exchange servers. Our lab testing is showing that it prefers using a ExDomain GCs even if a UserDomain GC is in the same site, but I can’t find any documentation on how the GC is selected in that case.  

  17. Hi Marc,

    When I made that comment we hadn’t fleshed out the work involved to simulate Pre-SP2 behavior.  During the development of the ‘RFR Prefer In-Site GCs’ solution, we found that we couldn’t revert to Pre-SP2 behavior due to the amount of code that was changed (have to balance change with dev/test costs with respect to the risk of destabilizing the product).  So we came up with the above solution.  I’m sorry it doesn’t work the way you would like…but the dedicated AD site isn’t hard to deploy; it doesn’t require a new IP subnet range or anything (you can create subnets with a /32 subnet mask), so you can simply scope out an Exchange AD site with the appropriate GCs and have your solution.  For more information, take a look at http://www.microsoft.com/technet/itsolutions/msit/operations/adforexchangenote.mspx.

    Yes, if you disable the referral service and force clients to proxy through the Exchange server, will preferentially use the GCs from the same domain as the Exchange server (like Pre-SP2 referral behavior); we didn’t modify the proxy code, only the referral behavior.

    Ross

  18. Marc C says:

    I posted something a while ago "We actually prefer the old algorithm, when we migrated to Exchange 2003 we planned ahead and put all the DLs in the same site of our Exchange servers (they are all in the same domain), users are scattered across 5 other domain. This way the DL update issue is negated, as for the delegate problem we had no way to design around it. Now we are swapping problems. Any chance that we can at least control the algorithm? BTW: Why don’t you guys get together with the Office team and fix the problem for real, this is a know problem since 1999, there is no reason other than motivation for this problem to exist?."

    Your response was "Stay tuned…I will be posting an update in the Dec/Jan timeframe that answers your issue. "

    If you were talking about the "RFR Prefer In-Site GCs" it doesn’t do anything to help us since we have overlapping Domains in the same site.  So even with this switch our client’s still get "permission denied" Popups when trying to modify DL that they in fact have permissions for.  The only alternative that was given to us with KB 912584 is to created a dedicated site for Exchange and our ExDomain GCs.

    Alternatively, we are looking into using the "NO RFR Service" switch and having all DS requests proxied by the Exchange servers. Our lab testing is showing that it prefers using a ExDomain GCs even if a UserDomain GC is in the same site, but I can’t find any documentation on how the GC is selected in that case.

Comments are closed.

Skip to main content