Exchange Server 2003 Service Pack 2 DSProxy Referral Process Changes
Published Nov 04 2005 12:25 PM 7,596 Views

Pre-Exchange Server 2003 Service Pack 2 Behavior

Prior to Exchange Server 2003 Service Pack 2, Outlook MAPI clients would receive either a referral to a global catalog server or use the Exchange server to proxy directory related requests; specifically, Outlook 2000 clients and above support and utilize the DSProxy Referral process by default (with the exception of Outlook 2003 RPC over HTTPS which utilizes the proxy mechanism with Exchange Server 2003 SP1 and later).  This means that after the Outlook client connects to the Exchange Server, the DSProxy service passes a referral back to the client.  From that point on, all future directory requests are sent directly to the referred global catalog server.

 

In this scenario, the global catalog will be from one of two locations:

 

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

2.    The GC 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 doesn’t 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.

 

Consider the following scenario:

The forest contains three domains, each of which has been prepared for Exchange.  All users and distribution groups reside in the domain, UserDomain.  A global catalog server from each domain is a member of the Exchange server’s AD site.  The Outlook clients reside in a different AD site. The Exchange server's domain is not represented and there are no global catalogs present in the Exchange AD site.

 

 

When an Outlook 2003 client connects to the Exchange server, DSProxy could potentially refer the client to any one of the three global catalog servers that exist in the Exchange server’s AD site, assuming that one or all of those global catalog servers are online and reachable.  DSProxy will load balance referral requests across the available global catalog servers to evenly distribute clients.

 

Considering the above design, there is basically a 66% chance that DSProxy will refer the Outlook client to a non-home-domain global catalog server.  So for the purpose of this discussion, let’s assume DSProxy refers the client to a ThirdDomain global catalog server.  In this scenario, the Outlook clients can use that global catalog server successfully for all directory requests except:

·         Updating membership of distribution groups that reside in UserDomain.

·         Assigning delegate permissions against their mailboxes (which reside in UserDomain).

·         Publishing certificates to the GAL (via Publish to GAL option in Outlook).

 

Now if DSProxy referred the Outlook client to the UserDomain GC1, then the Outlook client would be able to perform the above bullets. 

 

For more information about Pre-SP2 behavior and its potential issues, please see:

·         Exchange Server 2003 Technical Reference Guide – Directory Service Proxy - http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3TechRef/b7f8fbf4-732c-4a87-a9d5-3c4... 

·         XCLN: How MAPI Clients Access Active Directory - http://support.microsoft.com/?id=256976 

·         How to control the DSProxy process for RPC over HTTP connections in Exchange Server 2003 SP1 - http://support.microsoft.com/?id=872897

·         "Do not have sufficient permissions" error message occurs when you use Outlook Address Book to manage distribution list membership - http://support.microsoft.com/?id=318074   

·         "Send on behalf" permission is not assigned to a user after you delegate access in Outlook - http://support.microsoft.com/?id=329622

 

Exchange Server 2003 Service Pack 2 Behavior

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

 

Here is how the new algorithm will work:

 

The Exchange Server 2003 SP2 DSProxy service will try to refer the Outlook client to a global catalog server that resides in the mailbox owner’s home AD domain that is available and supports the protocol used by the client.  In order for DSProxy to find a global catalog server that meets those requirements, DSProxy will score the desirability of a given global catalog server based on the following 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

 

In other words, 16 points are assigned to a global catalog server that is available, 8 points if it supports the client’s protocol, 4 points if it’s in the mailbox owner’s domain, 2 points if it is in the Exchange Server’s site, and 1 point if it is in the list of currently used global catalog servers of the Exchange Server. DSProxy will hand out the global catalog servers with the most points first, and round-robin in the case of a tie. 

 

Constraint 1 is computed every 5 minutes and is configurable via the registry key LdapKeepAliveSecs.  Constraints 2 and 3 are “dynamic” in that they must be computed each time a client calls for a referral. Constraints 4 and 5 are “static” in that they are computed once for each GC and stored.

 

Constraint 5 is also known as the incarnation list.  When DSAccess initializes, it builds an incarnation list of 10 in-site global catalog servers that it can use.  If all in-site global catalog servers are unavailable, DSAccess will build an incarnation list of 10 out-of-site servers from the directly connected sites, starting with the site with the lowest site link cost.  Due to the constraint ordering, DsProxy prefers servers in DSAccess’ Incarnation list, so by default it will prefer the 10 servers with the lowest site link cost.  But DsProxy has a list of ALL global catalog servers in ALL directly connected sites and only uses membership in the incarnation list to assign points to servers.

 

So if we have the following scenario where there are two domains, ExDomain and UserDomain, designed as follows:

 

 

 

Then the global catalog servers will be assigned the following points by the DSProxy service (note that we are assuming that all global catalog servers are up and responsive within the Exchange AD site):

 

Server

Active Directory Site

In-Use by DSAccess?

Constraint

Total Points

1

2

3

4

5

UserDomain GC1

Client AD Site

No

16

8

4

0

0

16+8+4=28

UserDomain GC2

Client AD Site

No

16

8

4

0

0

16+8+4=28

UserDomain GC3

AD Site B

No

16

8

4

0

0

16+8+4=28

UserDomain GC4

AD Site B

No

16

8

4

0

0

16+8+4=28

ExDomain GC1

Exchange AD Site

Yes

16

8

0

2

1

16+8+2+1=27

ExDomain GC2

Exchange AD Site

Yes

16

8

0

2

1

16+8+2+1=27

ExDomain GC3

AD Site A

No

16

8

0

0

0

16+8=24

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

 

Note: As you can see from the table, ExDomain GC7 and UserDomain GC5 are not included because they are not directly connected to the Exchange server’s AD Site.  In other words, the Exchange server will never utilize those global catalog servers for DSAccess or DSProxy functions.

 

So from this example, you can see that this algorithm may prioritize an out-site global catalog server over an in-site global catalog server, which is different than normal pre-SP2 DSProxy behavior. 

 

In this particular example, Exchange will provide the UserDomain global catalog servers to the Outlook clients (in a round-robin fashion to load balance requests) due to those global catalog servers having a higher point calculation than the ExDomain global catalog servers.  This means that Exchange can refer clients to out-site global catalog servers (only those that are directly connected to the Exchange AD site though) now if there are no mailbox home-domain global catalog servers available within the Exchange server’s AD Site.  In this particular example, the Outlook client could receive a referral to a UserDomain global catalog server that is located in AD Site B or the Client AD Site. 

 

In addition, if all of the UserDomain global catalog servers were unreachable (i.e. those servers failed Constraint 1), DSProxy would refer the Outlook clients to the global catalog servers that reside in the Exchange AD Site, since they have the next highest point cost.

 

What Doesn’t the SP2 DSProxy Change Solve?

This change is only beneficial to the end user when DSProxy can find a home-domain global catalog server.  If there are no home-domain global catalog servers in the Exchange server’s AD site or in any of the Exchange server’s directly connected AD sites, then the Outlook client will receive a referral to a global catalog server that contains a read-only copy of the mailbox-enabled user.  This means that the mailbox in question will not be able make delegate modifications or publish certificates to the global address list.

 

In addition, while the new behavior may solve the delegate permission and certificate publishing issues, it may not address the mail recipient’s ability to update distribution group membership. The distribution group will have to belong to the same domain as the mail recipient in order for the mail recipient to update the membership.  If the distribution group does not belong to the same domain as the mail recipient, then updating the membership will fail.  As a result, you may still need to look at another solution to provide all users with the capability to update group membership.

 

Exchange Server 2003 Service Pack 2 DSProxy Behavior Implications

The following items will need to be reviewed in your infrastructure:

·         Unless there is prior consideration in terms of network design this change may result in clients being referred to undesirable global catalog servers from a network perspective (latency, bandwidth, utilization, number of hops).  It is recommended to consider network implications prior to implementation.

·         To ensure that Exchange continues to provide in-site global catalog referrals, you may need to add global catalog servers to the Exchange AD site for those domains that contain mailboxes that reside within the Exchange servers in that AD site.

·         At the time of this writing, there is no method by which you can change the Exchange Server 2003 SP2 DSProxy behavior to prioritize the use of in-site non-home-domain global catalog servers over out-site home-domain global catalog servers.

 

 

- Ross Smith IV

20 Comments
Not applicable
Wow! Good stuff! That is why I like this blog!
Not applicable
Does this mean that as long as at least one of the highest ranking GC's will respond, it/they will always get the requests and none will be sent to Exdomain. Could this create a load issue if there weren't enough GC's in the highest ranking?
Not applicable
Lee, yes if there is only one GC that meets the requirements (whether Pre-SP2 or SP2) then that GC will receive all the referral requests.
Not applicable
Not to shoot the messenger or something like that :)

With regard to the DL mofidication issue, why would it not be possible to put some intelligence into DSProxy and have it directly detect the domain of the DL and have it refer the client to the appropriate DC (in whatever site) for the intended modification? If it's able to detect the client's domain right now, then it should be able to detect (from the change requested by the client) that the DL is NOT in the same domain as the client and the change can not be executed on the client's DC. It should then say something to the effect "this change can only happen on DC-xyz, go there".

Considering that the DL mod piece that is not addressed here is arguably the most sought-after feature (well....maybe "second-most-sought-after" - after delegation), I'd think that, given the huge efforts you guys put into making SP2, you'd at least put something (even if not elegant) in there to ameliorate the pains people are experiencing right now in a multi-domain environment.

Or did you, and I'm just over-simplifying the solution?

All in all, nice write-up. And good work on the enhancements.
Not applicable
If I'm understanding this right, does that mean there is no way to force a user to use a GC in their own site? For example:

Lets say we centralized Exchange and consolidated to a couple of Exchange servers in Site A (Chicago). The users are in Site A of course, Site B (NY), Site C (Miami), Site D (L.A.), and site E (Denver). All sites have a GC, and all the users and servers are in the same domain (although not a single domain organization due to an empty root domain, for all intents and purposes it acts as a single domain. )

Obviously we would like a user in Miami to normally hit the GC in Miami, but it sounds like they will instead always hit Chicago. I understand that since the user has no IP address it would be hard to determine their site... :) but is there no way around this?

In any case thanks for the article, this blog really is great for learning stuff I'd probably never know otherwise...
Not applicable
Thanks for this excellent work.

Additional question. If Outlook is connected to a GC which is not in the users domain and the user adds a universal distribution group to a public folder ACL. This group should convert to a universal security group, does this happen in this case?

Regards
Not applicable
Thanks for this clear explanation.

I was just wondering what will will happen with GC requests that do get proxied, either because the client is pre Outlook 2000 or because the registry key that's enabling proxying all request is set. Does this new algorithm also goes for these kind of requests?
Not applicable
Wolfgang,

The store handles the conversion of the UDG to a USG.
Not applicable
Brian,


To force Outlook to use a GC within its own site rather than the Exchange GC referral, you need to implement one of two registry keys that are discussed in



http://support.microsoft.com/default.aspx?scid=kb;en-us;319206.

Not applicable
Deji,

No you are not oversimplifying the issue. We addressed the delegate issue and didn't address the distribution group membership issue (if the DG is not in the same domain as the referral GC).

As to why we didnt't include this functionality, well it all comes down to customer pain issues (delegates was at the top), development time constraints, and testing time constraints.

If you feel strongly about this scenario, then I would suggest you contact your TAM (you do have one don't you <grin>) so that they can escalate as appropriate.
Not applicable
Marcel,

We did not change the behavior in SP2 for how proxy requests are performed. We only changed the behavior for referrals.
Not applicable
Ross -

Thanks to the team for this wonderful update! Without going into too much detail, I have seen this issue twice.

Bob
Not applicable
Thanks for all the updates - this is invaluable...

Just one more question:
You mentioned KB319206 to force Outlook to use a GC within its own site. Does this mean that Outlook is "site-aware"? Meaning: Outlook sends a query(SRV) to DNS to find the closest GC?
Not applicable
Hi Christian,

The implementation for the 'Closest GC' option within Outlook 2002 and later utilizes the DSGetDCName API and not SRV records (DNS).
Not applicable
Hi Ross,

thanks for the update!
Not applicable
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?
Not applicable
Marc,

Stay tuned...I will be posting an update in the Dec/Jan timeframe that answers your issue.
Not applicable
I would like to clarify one specific detail, regarding the following:

> Considering the above design, there is
> basically a 66% chance that DSProxy will
> refer the Outlook client to a non-home-domain
> global catalog server. <snip> In this
> scenario, the Outlook clients can use that
> global catalog server successfully for all
> directory requests except:
>
> · Updating membership of distribution groups that reside in UserDomain.

My questions:

1.) Is this issue specific to *DISTRIBUTION* groups?

2.) Are *SECURITY* groups also similarly affected by this issue? (i.e. mail-enabled security groups)

thanks,
-Pete Heilig
Senior Systems Engineer
Gartner, Inc.



Not applicable
Any mail enabled group that is not in the same domain as the GC that the client is utilizing will prevent the client from updating the membership due to its read-only nature in the GC.
Not applicable
In November 2005 I posted an article on the DSProxy referral changes that are included in Exchange Server...
Version history
Last update:
‎Jul 01 2019 03:09 PM
Updated by: