2.7 Interaction between Global Catalogs and clients

 < Day Day Up > 



Global Catalog servers are tremendously important to Exchange clients. MAPI clients access the GAL through a GC, while Internet clients perform LDAP lookups against a GC to retrieve directory information. When compared with MAPI, the LDAP protocol is basic, so instead of depending on LDAP as a general-purpose access protocol for all Exchange clients, Microsoft uses NSPI, the Name Service Provider Interface. Only GCs support NSP, which means that MAPI clients cannot connect to a DC to retrieve the GAL.

For the purpose of GAL access, MAPI clients divide into two camps. Pre-Outlook 2000 clients base GAL access on the premise that every Exchange server has a dedicated directory service running on the same computer. Outlook 2000 and subsequent clients understand that the directory service can be located on another server elsewhere in the network. The Exchange DSProxy service handles incoming requests from clients for directory access and sends the requests on to a nearby GC for resolution. During a session, DSProxy has to handle every directory access request from pre-Outlook 2000 clients and proxy them on to a GC. In other words, every time a pre-Outlook 2000 client connects to Exchange, DSProxy has to locate the most appropriate GC and pass on the requests to that GC.

Persistent referrals began with Outlook 2000 by being truly persistent. In this case, the lookup to locate the GC happens once, and after that Outlook 2000 always attempts to connect to the same GC without consulting DSProxy. The client holds the fully qualified domain name of the GC in its MAPI profile and uses it each time Outlook 2000 starts a session. If the GC is unavailable, the client then refers to Plan B and asks DSProxy for another referral, and the cycle starts again. This scheme works, but it is flawed since there is no way to implement load balancing or to select a more appropriate GC if one becomes available after Outlook 2000 has written details of the selected GC into its MAPI profile. Accordingly, from Outlook 2000 SP2 onward, the client ignores any information held in the MAPI profile and always consults DSProxy to determine what the best GC is at that point in time and then makes a connection to that GC. You can also control Outlook and point it to a specific GC by writing the fully qualified domain name of the GC into the following registry key:

HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider Value Name: DS Server (REG_SZ) Value Data: FQDN of preferred GC

While you can exercise a certain amount of control over client GC selection, you can do nothing to assure a smooth failover for a client if the GC goes offline. At worst, Outlook will freeze solid. At best, you see that you cannot contact the directory. In all cases, the easiest thing to do is to exit Outlook and restart the client to force DSProxy to select a new GC.

Outlook 2003 includes a neat feature to help you understand the connections that exist between client and server. To see the information, hold down the CTRL key when you click on the Outlook icon in the system tray and then select the "Connection Status" option to force Outlook to display the form shown in Figure 2.21. Outlook lists the connections it maintains to GCs and the mailbox server. The number of instances reported for each server attests to the multithreaded nature of communications between Outlook, Exchange (including any public folder replicas you are connected to), and AD. You are also able to see if any failures have occurred on a link and the average response time (in milliseconds). The "Avg Proc" column shows how many milliseconds the server spends compressing the RPC data for the client. For example, you can see that Outlook reports that the average response for the first "Mail" connection in Figure 2.21 is 19 milliseconds, and the server spends 3 milliseconds compressing the data. In effect, this means that the real round-trip time between server and client is 16 milliseconds. You can also see the version number of the Exchange server Outlook connects. In this instance, we can see that the servers hosting the mailbox and public folders run different builds of Exchange. The "Local Mailbox" tab on the Connection Status form allows you to monitor any replication activity that Outlook is currently processing. For example, if Outlook is downloading new messages into the Inbox, you will see this information listed here.

click to expand
Figure 2.21: Outlook connections to Exchange.

2.7.1 How many GCs do I need?

Determining just how many GCs are required to handle the load generated by Exchange is an interesting exercise. Among the factors that influence the decision are:

  • AD design: If you are lucky enough to be able to deploy Exchange inside a single domain, by definition, all of the domain controllers are GCs and Exchange can use them for this purpose, since each controller holds a complete copy of all objects-configuration and user-for the entire forest. Through its suitability tests, DSAccess may select different controllers for different jobs, but every controller holds the same information. Contrast this to the situation in a multidomain forest, where GCs hold information significantly different from DCs. While the DSAccess suitability tests will locate the most suitable DC and GC for Exchange to use, DSAccess depends on the SRV records registered by DCs and GCs in the AD to know which computers offer these services. Therefore, it is essential that DNS operates reliably-this factor increases in importance with the number of controllers in the forest.

  • Application load: Exchange depends on GCs for many purposes, including the expansion of distribution groups and validation of email addresses. Other applications may also use GCs and therefore contribute to the overall load that the environment generates on the GCs. Small deployments may consider using a single server to host both the GC and Exchange. It is best practice to avoid all-inclusive servers for corporate deployments, because their configuration is more complex, especially in the case of a failure and restore exercise, and because you can compromise AD security if many administrators have physical access to a domain controller.

  • Available hardware: Clearly, a multi-CPU server equipped with 2 GB of memory is capable of supporting a heavier workload than a single-CPU server with 256-MB supports. As with most database applications, the AD is able to use memory to cache data and reference the data in memory instead of going to disk, so servers that have more memory usually help it to support a greater workload. Additional CPUs allow the server to partition the load generated by applications and avoid situations where a single application swamps the system with its demand. Some AD deployments may have commenced using older servers as DCs and GCs and find that the performance of these servers struggles as application load increases, perhaps because of a migration to Exchange. If you enhance the hardware for these servers, it will let them support more application demand. The alternative is to deploy additional servers, an unattractive option because it increases management workload.

  • The number of mailboxes supported per server: Servers that support large mailbox populations generate higher loads on GCs than smaller servers do. For example, it is easy to appreciate that a server supporting 4,000 mailboxes generates a higher load than one supporting 500 mailboxes. Thus, as server numbers reduce through consolidation projects, it is important to focus on the overall number of mailboxes in the organization instead of concentrating purely on the number of servers.

With these points in mind, the usual starting points for any discussion about GC numbers and placement are:

  • Make sure that every Exchange server is close to a GC and that every Windows site that hosts an Exchange server also has a GC. In this context, close means that the two servers are ideally on the same network segment or as near to this situation as you can achieve. Every network interruption causes problems for both the Exchange server and Outlook clients, so keeping a GC in close network proximity is a wise choice. The danger signal is when Outlook clients have problems retrieving information from a GC when users validate addresses in message headers, as shown in Figure 2.22. If you use Outlook 2003, you can reduce the user perception of the problem by running Outlook in cached Exchange mode and let "drizzle" background synchronization take care of communications. However, while cached Exchange mode helps, it cannot fix a fundamental problem caused by GC unavailability.

    click to expand
    Figure 2.22: Outlook 2002 has problems talking with a GC.

  • In large Windows sites, make sure that you have at least one GC for every four Exchange processors. Originally, the recommendation was to have one GC for every four Exchange servers, but it has changed over time to reflect the fact that a large percentage of Exchange servers are multiprocessor systems. This is a rule of thumb and not a design principle that you need to follow always. In particular, if servers support large mailbox populations, monitor the workload generated on the GCs and add extra controllers once the GCs show any sign of stress. For example, inside HP, the design rule is: Begin with one GC everywhere we install an Exchange server and then add an extra GC for every 4,000 mailboxes.

  • Consider creating a special AD site for Exchange servers and install GCs within the site for Exchange to use. The DSAccess suitability tests always prefer GCs that are within the same AD site as the Exchange server. This approach also keeps other demands (such as expanding distribution groups during the Windows logon process) away from the GCs that serve Exchange, which may be important in large deployments.

  • To avoid possible performance problems, ensure that Exchange servers do not select the GC that Windows uses as the PDC emulator.[5] The PDC emulator usually experiences a heavy workload to handle account updates, and acting as a preferred GC for Exchange may introduce enough additional workload to affect the response to clients. For the same reason, you should avoid using GCs that handle intersite AD replication traffic as much as possible. In small AD deployments, this should not be a factor, since any server should be able to handle the replication traffic, but it can certainly cause concern inside large deployments.

  • Always avoid a single point of failure. Because Exchange and Outlook depend so heavily on the GC, always make sure that a failure of one GC will not affect your users to a noticeable degree. You can configure Outlook 2002 (or later) clients to contact the "closest" GC or a preferred GC, which may be useful if you want to control exactly which GCs Outlook uses.[6]

While best practice is to separate Exchange from AD servers, you can certainly run Exchange 2003 on a server that also hosts the AD, and you may want to do so in small branch offices where hardware is limited. However, there are some points to bear in mind. First, you cannot run this configuration on a cluster, because Microsoft does not support Exchange and AD coexistence on a cluster. Second, the server must be a GC rather than a DC. Performance can be an issue, so Exchange and AD both like to absorb system resources, but in small branch offices, the server probably handles a limited user community, since any reasonably sized computer will be able to handle the load. When you run the two components on the same server, system shutdown is slower than normal, since DSAccess will time out several times before it shuts down, because the AD process (LSASS.EXE) shuts down before Exchange. You can avoid this issue by stopping the Information Store process manually before shutting down the system. Security is the biggest issue in coexistence. If Exchange administrators can log on at the server console, they can potentially elevate their permissions and gain access to restricted data. Obviously, you should trust your system administrators, but even so, it is best practice to avoid logons at the system console.

2.7.2 The GC logon cache

The GC logon cache is a new feature in Windows 2003 that can restrict the need to deploy additional GCs to resolve the membership of universal groups during the logon process. When a user authenticates by providing his or her credentials to a DC, Windows builds a security token that contains details of all the groups the user belongs to. For the DC to build the token, it has to resolve the membership of the groups, and the only way it can do this is by reference to a GC. Remember, only a GC contains details of the membership of universal groups, so given that Exchange is a major consumer of universal distribution groups, the accurate resolution of group membership is another reason why GCs are so important to Exchange. However, while it is good to contact a reliable source to resolve group membership, this can sometimes lead to situations where large organizations have to deploy more GCs than they want, especially inside Windows sites that serve small branch offices. The GC logon cache allows a Windows 2003 DC to maintain a local cache of group membership in its local AD database that it prefetches or periodically resolves against a GC. Thus, clients can authenticate themselves against a DC and have their group membership fully resolved if the details already exist in the cache. Note that a user must log on and successfully authenticate with a GC present before the local DC can cache his or her group membership. Group membership data exists in the local cache until it expires, normally after eight hours. You can change the expiration period by modifying the registry as follows (value in minutes):

Key:HKLM\System\CurrentControlSet\Services\NTDS\Parameters\ Value:Cached Membership Site Stickiness (DWORD)

Microsoft Knowledge Base article 241789 describes a workaround for Windows 2000 that instructs domain controllers to ignore GCs during user authentication.

Microsoft's idea is that you can reduce the number of GCs you deploy by only having the need to deploy DCs in each Windows site. In this scenario, the DCs need to connect to GCs to fetch group membership data, but you can keep these GCs at a central location and manage them there. Potentially, this gives you another advantage, because central sites often link together with high-speed ATM connections, so fast replication is seldom an issue. To enable the GC cache, you select the NTDS Site Settings object for the Windows site through the AD Sites and Services console and modify its properties, as shown in Figure 2.23. You can see that in this case, the Houston site refreshes its GC cache from the Dublin site. The cache refreshing interval is based on the replication schedule for the site link.

click to expand
Figure 2.23: Enabling the GC cache.

As you deploy Windows 2003 DCs, you may decide to implement the GC logon cache. Before you do, be aware that this feature exposes a potential for someone to access information that is usually unavailable. For example, assume that you remove a user from a group that protects a public folder that holds sensitive information. The user's workstation is part of a Windows site that uses the GC logon cache. The problem occurs when the user has either not logged on recently (to pick up his or her new group membership) or the DC has not refreshed the local GC logon cache. In either case, it is conceivable that the user can continue to access the public folder, because the security token that the DC constructs during the logon process continues to include the credentials granted to the group.

All of this proves that the provision of a new feature that Microsoft intends to solve a particular problem (in this case, the deployment of too many GCs to serve small branch offices) can have an unfortunate side effect on an application, if you deploy it without thinking through the consequences. Best practice is, therefore, to keep existing GCs in place unless you are positive that they are no longer required.

[5] . See Knowledge Base article 298879 for more information.

[6] . See Knowledge Base articles 319206, 317209, and 272290.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net