Directory Service Proxy

Directory Service Proxy (DSProxy) is the Exchange Server 2003 component that provides an address book service to Microsoft Office Outlook clients. DSProxy is implemented in DSProxy.dll and has two functions:

• To emulate a MAPI address book service and proxy requests to an Active Directory server

• To provide a referral mechanism so that Outlook clients can directly contact Active Directory servers

Although its name implies that it provides proxy services only, DSProxy provides both proxy and referral services.

MAPI clients that are running versions of Outlook earlier than Outlook 2000 access the directory through the DSProxy component. These earlier clients were designed with the assumption that each Exchange server contains a directory service. In Exchange 2000 Server and later versions, this is no longer the case. Therefore, DSProxy emulates a directory service so that earlier clients can function by having the Exchange 2003 server forward the requests to Active Directory.

Later versions of Outlook, such as Outlook 2000 and Outlook 2002, still use a Name Service Provider Interface (NSPI) proxy on the initial connection to Exchange Server. However, after the client contacts the server, the DSProxy service passes a referral back to the client. From that point on, all future directory requests are sent directly to the referral server. The referral server in this case is the global catalog server.

DSProxy obtains its list of working global catalog servers from DSAccess but it does not route its queries through DSAccess. This is because DSProxy uses the NSPI to submit MAPI address book lookups. DSAccess handles only LDAP queries. However, DSProxy fully relies on DSAccess to provide global catalog failover support.

DSProxy performs the following operations.

• It acquires the list of working global catalogs from DSAccess and filters out global catalogs that are not suitable.

• It proxies MAPI queries from pre-Outlook 2000 clients to the global catalog servers, based on the number of global catalogs and the client IP.

• It refers Outlook 2000 and later version clients to global catalog servers by using a round robin mechanism.

DSProxy at first runs as a single thread, which can support as many as 512 client connections. DSProxy automatically spawns an additional thread for every 512 connections. Unlike DSAccess, DSProxy has no caching mechanism. This means that every MAPI query processed through DSProxy is sent to a working global catalog.

There was a design change in Exchange Server 2003 Service Pack 2 (SP2) for how the DSProxy service refers to Outlook clients in global catalogs. This topic explains the before and after behavior of this change.

Before Exchange Server 2003 SP2, Outlook MAPI clients would receive either a referral to a global catalog server or they would use the Exchange server to send directory-related requests. In the scenario where the client is Outlook 2000, 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 is from one of two locations:

• The global catalog is located in the same Active Directory site as the Exchange server (typical behavior).

• The global catalog is located in an Active Directory site that is directly connected to the Exchange server’s Active Directory site (when all in-site global catalogs 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 there are none available, DSProxy uses the other global catalog servers in the Active Directory site.

This behavior presents issues in multiple-domain environments where DomainPrep has been run 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, that user will access data that is in a read-only format. This means that updates to certain objects could fail. The updates could be updates to the mailbox-enabled user such as delegate access or distribution group membership.

The forest contains three domains, each of which has been prepared for Exchange Server. All users and distribution groups reside in the domain, UserDomain. A global catalog server from UserDomain and ThirdDomain are members of the Exchange server’s Active Directory site. The Outlook clients reside in a different Active Directory site. The domain of the Exchange server is not represented and there are no global catalog servers from that domain in the Exchange Server Active Directory 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 in the Exchange server’s Active Directory site, assuming that one or more of these global catalog servers are online and reachable. Because there are no global catalog servers that are members of the Exchange server's domain, the pre-SP2 behavior does not prefer any of the global catalog servers over any other. DSProxy will load-balance referral requests across the available global catalog servers to evenly distribute clients.

In considering the above design, there is a 66 percent chance that DSProxy will refer the Outlook client to a global catalog server not in the client's home domain. For the purposes of this discussion, assume that 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 the following:

• Updating membership of distribution groups that reside in UserDomain.

• Assigning delegate permissions against the mailboxes of these distribution groups, which reside in UserDomain.

• Publishing certificates to the global address list (GAL) using the Publish to GAL option in Outlook.

If DSProxy referred the Outlook client to the UserDomain GC1, the Outlook client could perform the requests listed above.

For more information about pre-SP2 behavior and its potential issues, see the following Microsoft Knowledge Base articles.

• 256976, "XCLN: How MAPI Clients Access Active Directory"

• 872897, "How to control the DSProxy process for RPC over HTTP connections in Exchange Server 2003 sp1"

• 318074, ""Do not have sufficient permissions" error message occurs when you use Outlook Address Book to manage distribution list membership"

• 329622, ""Send on behalf" permission is not assigned to a user after you delegate access in Outlook"

In Exchange Server 2003 SP2, by using a new algorithm, the referral process now tries to provide the Outlook client with a global catalog that belongs to the same domain as the mailbox-enabled user. The new algorithm will solve the delegation issue, if a home-domain 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. If it does not reside in the same domain, it will not address the issue because the global catalog contains a read-only copy of the distribution group.

The Exchange Server 2003 SP2 DSProxy service tries to refer the Outlook client to a global catalog server that is available, supports the protocol that is used by the client, and resides in the mailbox owner’s home Active Directory domain. For DSProxy to find a global catalog server that meets those requirements, DSProxy scores the desirability of a particular global catalog server based on the following constraints:

• Constraint 1   A global catalog that is available (RPC ping) – 16 points

• Constraint 2   A global catalog that supports the client's protocol – 8 points

• Constraint 3   A global catalog that belongs to the user's domain – 4 points

• Constraint 4   A global catalog that is in the same Active Directory site as the Exchange server – 2 points

• Constraint 5   A global catalog that is one of the global catalogs that the Exchange server is currently using – 1 point

DSProxy distributes the global catalog servers that have the most points first, and sequentially allocates resources if there is a tie.

Constraint 1 is computed every five minutes and is configurable through changing the LdapKeepAliveSecs registry key. Constraints 2 and 3 are "dynamic" because they must be computed every time that a client demands a referral. Constraints 4 and 5 are "static" because they are computed one time for each global catalog and then 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 builds an incarnation list of 10 out-of-site servers from the directly connected sites, starting with the site that has the lowest site link cost. Because of the constraint ordering, DSProxy prefers servers in the incarnation list of DSAccess so that by default, it will prefer the 10 servers that have the lowest site link cost. However, 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.

The following figure shows the scenario where there are two domains, Exchange Domain and UserDomain.

In this scenario, the global catalog servers will be assigned the points by the DSProxy service as shown in the following table. Be aware that the assumption is made that all global catalog servers are up and responsive in the Exchange Active Directory site.

From this example, you can see that this algorithm may prioritize an out-of-site global catalog server over an in-site global catalog server, which differs from typical pre-SP2 DSProxy behavior.

In this example, Exchange Server provides the UserDomain global catalog servers to the Outlook clients (in a sequential manner to load-balance requests) because those global catalog servers have a greater point calculation than the Exchange Domain global catalog servers. This means that Exchange can now refer clients to out-of-site global catalog servers (but only those that are directly connected to the Exchange Active Directory site) if there are no mailbox home-domain global catalog servers available in the Exchange server’s Active Directory site. In this particular example, the Outlook client could receive a referral to a UserDomain global catalog server that is located in Active Directory site B or the Client Active Directory site.

Additionally, if all the UserDomain global catalog servers were unreachable (that is, those servers failed Constraint 1), DSProxy would refer the Outlook clients to the global catalog servers that reside in the Exchange Active Directory site, because they have the next highest point cost.

For more information about post-SP2 DSProxy referral, see the Exchange Server Team blog article Exchange 2003 post-SP2 DSProxy Referral Update.

The DSProxy referral change helps the end-user only when DSProxy can find a home-domain global catalog server. If there are no home-domain global catalog servers in the Exchange server’s Active Directory site or in any of the Exchange server’s directly-connected Active Directory sites, the Outlook client receives a referral to a global catalog server that contains a read-only copy of the mailbox-enabled user. This read-only access means that the mailbox in question cannot make delegate modifications or publish certificates to the (GAL).

Additionally, although the new behavior could solve the delegate permission and certificate publishing issues, it might not address the mail recipient’s ability to update distribution group membership. The distribution group must belong to the same domain as the mail recipient for the mail recipient to update the membership. If the distribution group does not belong to the same domain as the mail recipient, updating the membership will fail. Therefore, you may still have to examine another solution to provide all users with the capability to update group membership.

The following items must be reviewed in your infrastructure:

• Unless there is prior consideration with regard to network design, this change may cause clients to be referred to incorrect global catalog servers from a network perspective (latency, bandwidth, usage, number of hops). We recommend that you consider network implications before implementation.

• To ensure that Exchange Server continues to provide in-site global catalog referrals, you may need to add global catalog servers to the Exchange Active Directory site for those domains that contain mailboxes residing on the Exchange servers in that Active Directory site.