Exchange 2003 post SP2 DSProxy Referral Update

Weekend Reading

subject: exchange — Sat, 18 Mar 2006 17:26:51 GMT

Microsoft renames ActiveSync to Windows Mobile Device Center
Life Without Exchange
Microsoft's Exchange...

re: Exchange 2003 post SP2 DSProxy Referral Update

joe — Sat, 18 Mar 2006 22:27:05 GMT

Good post Ross, I enjoyed it.

re: Exchange 2003 post SP2 DSProxy Referral Update

Thomas K.H. Bittner — Mon, 20 Mar 2006 10:17:53 GMT

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.

re: Exchange 2003 post SP2 DSProxy Referral Update

Ross Smith IV — Mon, 20 Mar 2006 19:23:34 GMT

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

Post SP2 DSProxy update

Gerod Serafin's WebLog — Mon, 20 Mar 2006 21:08:30 GMT

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

re: Exchange 2003 post SP2 DSProxy Referral Update

EngineerBoy — Tue, 21 Mar 2006 21:57:07 GMT

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?

re: Exchange 2003 post SP2 DSProxy Referral Update

Ross Smith IV — Wed, 22 Mar 2006 20:13:40 GMT

EngineerBoy,

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

Ross

re: Exchange 2003 post SP2 DSProxy Referral Update

Adolfo Guzman — Sat, 25 Mar 2006 16:36:06 GMT

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_USER\Software\Microsoft\Exchange
\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_USER\Software\Microsoft\Exchange
\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.

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?

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

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

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

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

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

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

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 — 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