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.