Many changes that occur beneath the surface of Exchange are easily overlooked, but are also important for administrators to know about. In Exchange 2003 Service Pack 2 (SP2), an updated algorithm makes it more likely that users will have write access to objects in their domain when they need it.

Exchange depends on Active Directory (AD) for information about mail-enabled objects as well as configuration-data about its own organization. Outlook clients also depend on AD, but only to access the Global Address List (GAL), which they do by connecting to a Global Catalog (GC) server that has a copy of all mail-enabled objects in the AD forest. The Exchange DSProxy service maintains a list of GCs and refers Outlook clients to a suitable GC as needed. The referral process, which originated in Exchange 2000 Server, works well in single-domain forests but not as well in multidomain forests because of the read-only nature of the data for other domains maintained by each GC.

Although each GC holds a copy of all mail-enabled objects in the AD forest, it has only a partial copy of the objects from other than its own domain. If you want to retrieve an email address or access some information about a user from the GAL, such as a telephone number or a manager's name, you can do so because the GC has that data, even for mail-enabled objects in other domains. In other words, read-only access to any object in the GAL from anywhere in the forest isn't a problem.

However, if you want to write to an object—for example, update the delegate access on your mailbox, change the membership of a Distribution Group (DG), or publish certificates to the GAL—you can do so only when the object you want to update is in the same domain as your account.

In pre-SP2 Exchange 2003, DSProxy selects GCs from the same AD site and domain as the Exchange server. When more than one suitable GC is available, DSProxy attempts to load-balance client connections across the available GCs. If a GC from the same AD site and domain isn't available, DSProxy selects a GC from the same AD site or from an AD site that's directly connected to the site the Exchange server belongs to. In either case, the client is connected to a GC that doesn't belong to its domain. If Outlook ends up with a connection to a GC that isn't on the same domain as your account, you can't write to objects in your domain even if you possess all the necessary permissions. The reason is simple: You're connected to a GC that doesn't have a writeable copy of your data. (For more details about how Outlook connects to GCs via DSProxy and the problems that clients encounter, see the Microsoft articles "XCLN: How MAPI Clients Access Active Directory," http://support.microsoft.com/?kbid=256976; "'Send on behalf' permission is not assigned to a user after you delegate access in Outlook," http://support.microsoft.com/?kbid=329622; and "'Do not have sufficient permissions' error message occurs when you use Outlook Address Book to manage distribution list membership," http://support.microsoft.com/?kbid=318074.)

In Exchange 2003 SP2, Microsoft updated the GC selection algorithm to increase the probability of Outlook receiving a referral to a GC that's in the same domain as the user's account. DSProxy might still refer Outlook to a GC that doesn't belong to the same domain as the user's account, but if you use good deployment and planning practices to ensure availability of suitable GCs, the vast majority of Outlook referrals will likely be made to an appropriate GC.

The new algorithm works by scoring all available GCs according to their attributes, then selecting the GC with the highest score. A DSAccess list of GCs is computed when the Exchange System Attendant process starts up. The list contains 10 suitable GCs that Exchange can use, ordered first by GCs at the same site, followed by GCs from other sites according to the site link cost.

This subtle change in DSProxy behavior should enable more client referrals to GCs that let users at least update settings such as certificates on their own accounts. Some referrals will let users update DGs that they manage, but no referral will let a user update a group from another domain. To solve this problem, you need to assign group management to a user whose account belongs to the same domain as the group or move groups into the managing user's domain. Alternatively, you can write your own distribution list (DL) management tools (many large enterprises do this, especially when they have to deal with groups from heterogeneous email platforms) or use third-party tools to manage the content of groups. In either case, you lose the ability to manage group membership from Outlook.

From a planning perspective, to avoid problems with write access to GC data, you can deploy one domain to support both your Exchange servers and your user accounts. Every domain controller (DC) is then by definition a GC, and because everything belongs to one domain, users can update their own accounts and groups from Outlook.

However, operating a single domain isn't feasible for organizations that have already deployed a multidomain environment or for those that need the administrative flexibility of multiple domains. Such organizations can only ensure that their infrastructure contains enough GCs to let DSProxy make the right referral decisions for clients.

Exchange can be a complex beast. However, the updated algorithm in Exchange 2003 SP2 has improved the product and fixed a minor glitch. Administrators and users will notice.