Exchange 2003 post SP2 DSProxy Referral Update

re: Exchange 2003 post SP2 DSProxy Referral Update

Marc C — Tue, 09 May 2006 01:32:24 GMT

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.

re: Exchange 2003 post SP2 DSProxy Referral Update

Ross Smith IV — Wed, 03 May 2006 02:34:48 GMT

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

re: Exchange 2003 post SP2 DSProxy Referral Update

Marc C — Mon, 01 May 2006 23:27:05 GMT

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.

re: Exchange 2003 post SP2 DSProxy Referral Update

Ross Smith IV — Fri, 21 Apr 2006 05:47:39 GMT

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

re: Exchange 2003 post SP2 DSProxy Referral Update

Ross Smith IV — Fri, 21 Apr 2006 05:46:48 GMT

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

re: Exchange 2003 post SP2 DSProxy Referral Update

Kevin — Fri, 31 Mar 2006 00:43:29 GMT

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

re: Exchange 2003 post SP2 DSProxy Referral Update

Tom Mock — Wed, 29 Mar 2006 22:55:14 GMT

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?

re: Exchange 2003 post SP2 DSProxy Referral Update

Ross Smith IV — Wed, 29 Mar 2006 20:24:28 GMT

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

re: Exchange 2003 post SP2 DSProxy Referral Update

Ross Smith IV — Wed, 29 Mar 2006 20:20:53 GMT

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

re: Exchange 2003 post SP2 DSProxy Referral Update

Jens — Wed, 29 Mar 2006 10:19:11 GMT

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?