Defining the Global Catalog

 < Day Day Up > 

The Global Catalog is an index of the Active Directory database that contains a partial copy of its contents. All objects within the AD tree are referenced within the Global Catalog, which enables users to search for objects located in other domains. Every attribute of each object is not replicated to the Global Catalogsonly those attributes that are commonly used in search operations, such as first name, last name , and so on.

Global catalog servers, commonly referred to as GCs or GC/DCs, are Active Directory domain controllers that contain a copy of the Global Catalog. Locating a minimum of one Global Catalog server in each physical location is a wise move, because the Global Catalog must be referenced often by clients , and the traffic across slower WAN links would limit this traffic. In addition, technologies such as Exchange Server 2003 need fast access to Global Catalog servers for all user transactions, making it very important to have a Global Catalog server nearby.

Understanding the Relationship Between Exchange Server 2003 and the AD Global Catalog

In the past, an Exchange server could continue to operate by itself with few dependencies on other system components. Because all components of the mail system were locally confined to the same server, downtime was an all-or-nothing prospect. The segregation of the directory into Active Directory has changed the playing field somewhat. In many cases, downlevel clients no longer operate independently in the event of a Global Catalog server failure. Keep this in mind, especially when designing and deploying a domain controller and Global Catalog infrastructure.

NOTE

Because Outlook clients and Exchange can behave erratically if the Global Catalog they have been using goes down, it is important to scrutinize which systems receive a copy of the global catalog. In other words, it is not wise to set up a Global Catalog domain controller on a workstation or substandard hardware, simply to offload some work from the production domain controllers. If that server fails, the effect on the clients is the same as if their Exchange server failed.


Understanding Global Catalog Structure

The Global Catalog is an oft-misunderstood concept with Active Directory. In addition, design mistakes with Global Catalog placement can potentially cripple a network, so a full understanding of what the Global Catalog is and how it works is warranted.

As mentioned earlier, Active Directory was developed as a standards-based LDAP implementation, and the AD structure acts as an X.500 tree. Queries against the Active Directory must therefore have some method of traversing the directory tree to find objects. This means that queries that are sent to a domain controller in a subdomain need to be referred to other domain controllers in other domains in the forest. In large forests, this can significantly increase the time it takes to perform queries.

In Active Directory in Windows 2000/2003, the Global Catalog serves as a mechanism for improving queries. The Global Catalog contains a partial set of all objects (users, computers, and other AD objects) in the entire AD forest. The most commonly searched attributes are stored and replicated in the Global Catalog (that is, first name, username, email address). By storing a read-only copy of these objects locally, full tree searches across the entire forest are accomplished significantly faster. So, in a large forest, a server that holds a copy of the Global Catalog contains information replicated from all domains in the forest, as illustrated in Figure 8.2.

Figure 8.2. Global catalog replication.

graphics/08fig02.gif

Creating Global Catalog Domain Controllers

With the exception of the first domain controller in a domain, all domain controllers in Active Directory are not Global Catalog servers by default; they must first be established as such through the following procedure:

  1. Open Active Directory Sites and Services.

  2. Navigate to Sites, sitename , Servers, servername .

  3. Right-click NTDS Settings and then select Properties.

  4. Check the box labeled Global Catalog, as indicated in Figure 8.3.

    Figure 8.3. Creating a Global Catalog server.

    graphics/08fig03.gif

After being made into Global Catalog servers, domain controllers then receive their read-only copy of the partial domain naming context from each domain in the forest. To remove a domain controller from Global Catalog duties , uncheck the box; the DC will no longer hold a copy of the GC information.

NOTE

In large forests, replicating a full set of Global Catalog information can be a time- and bandwidth-consuming activity. Schedule the creation of Global Catalog servers during periods of low network activity, such as over an evening or weekend .


Verifying Global Catalog Creation

When a domain controller receives the orders to become a Global Catalog server, there is a period of time when the GC information will replicate to that domain controller. Depending on the size of the Global Catalog, this could take a significant period of time. To determine when a domain controller has received the full subset of information, use the replmon (replication monitor) utility from the Windows Server 2003 support tools. The replmon utility indicates which portions of the AD database are replicated to different domain controllers in a forest, and how recently they have been updated.

replmon enables an administrator to determine the replication status of each domain naming context in the forest. Because a Global Catalog server should have a copy of each domain naming context in the forest, determine the replication status of the new GC with replmon . For example, the fully replicated Global Catalog server in Figure 8.4 contains the default naming contexts, such as Schema, Configuration, and DnsZones, in addition to domain naming contexts for all domains. In this example, both the companyabc.com domain and the europe.companyabc.com domain are replicated to the ELG-DC1 domain controller.

Figure 8.4. ReplMon GC creation verification.

graphics/08fig04.gif

Using Best Practices for Global Catalog Placement

The general rule of thumb with GC placement is to place at least one GC in close network proximity to any major service that requires use of the Global Catalog (3268) port. Exchange Server 2003 makes extensive use of this port, and it is therefore wise to include a local GC in any site that contains an Exchange Server.

These requirements do not mean that an unnecessary number of Global Catalog servers need to be deployed, however. In reality, the total number of GCs that need to be deployed can be reduced in many situations through the concept of site consolidation in Exchange Server 2003. This concept enables multiple physical sites to use a central Exchange Server or set of servers, as opposed to having Exchange Servers (and their corresponding GCs) deployed to each site. Site consolidation works by having remote clients use the improved client remote access capabilities of Outlook 2003, OWA, and OMA. For more information on site consolidation strategies, see Chapter 4, "Exchange Server 2003 Design Concepts."

Optimizing Global Catalog Promotion

As previously mentioned, domain controllers can easily be promoted or demoted into Global Catalog servers with a single check box. The ease of this operation should not be taken lightly, however, because there can be a significant impact on network operations during this procedure.

When promoting a domain controller to Global Catalog status, the server immediately writes SRV records into DNS indicating its status as a Global Catalog server. In the past, this would cause problems, because Exchange 2000 servers would immediately begin using the incomplete Global Catalog on a newly created GC server, which would yield improper results. Upon the release of Service Pack 2 for Exchange 2000 and subsequently Exchange Server 2003, a mechanism for detecting the readiness of a Global Catalog server was built into Exchange, specifically into the DSAccess service. This prevented Exchange from using those GCs until it received a full copy of the Global Catalog.

NOTE

After a domain controller has been promoted to Global Catalog status, the server will require a reboot at some point. Although an administrator who sets up a GC server will never be prompted to reboot, the Name Service Provider Interface (NSPI) service, which is used by Outlook for address book lookups, will not function properly until the newly promoted GC server has been rebooted. In general, Exchange should be able to proxy this service for the clients, but it is still a good idea to plan for a reboot of a GC shortly after its creation.


Exploring Global Catalog Demotion

Removing a Global Catalog server from production can also have a detrimental effect in certain cases. Outlook 2000-and-older clients, for example, experience lockup issues if the Global Catalog server they have been using is shut down or removed from GC service. The loss of a GC server is the equivalent of the loss of an Exchange server, and should therefore not be taken lightly. Outlook 2002-and-greater clients, however, automatically detect the failure of their Global Catalog server and reroute themselves within 30 seconds. Scheduling Global Catalog or domain controller demotions for the off-hours, therefore, is important.

NOTE

If a production Global Catalog server goes down, downlevel (pre-2002) versions of Outlook can regain connectivity via a restart of the Outlook client. In some cases, this means forcing the closure of OUTLOOK.EXE and MAPISP32.EXE from the Task Manager or rebooting the system.


Deploying Domain Controllers Using the Install from Media Option

When deploying a remote site infrastructure to support Exchange Server 2003, take care to examine best practice deployment techniques for domain controllers in order to optimize the procedure. In the past, deploying domain controller and/or Global Catalog servers to remote sites was a rather strenuous affair. Because each new domain controller would need to replicate a local copy of the Active Directory for itself, careful consideration into replication bandwidth was taken into account. In many cases, this required one of these options:

  • The domain controller was set up remotely at the start of a weekend or other period of low bandwidth.

  • The domain controller hardware was physically set up in the home office of an organization and then shipped to the remote location.

This procedure was unwieldy and time-consuming with Windows 2000 Active Directory. Fortunately, Windows Server 2003 addressed this issue through use of the Install from Media option for Active Directory domain controllers.

The concept behind the media-based GC/DC replication is straightforward. A current, running domain controller backs up the directory through a normal backup process. The backup files are then copied to a backup media, such as a CD or tape, and shipped to the remote GC destination. Upon arrival, the dcpromo command can be run with the /adv switch ( dcpromo /adv ), which activates the option to install from media, as illustrated in Figure 8.5.

Figure 8.5. Install from media option.

graphics/08fig05.gif

After the dcpromo command restores the directory information from the backup, an incremental update of the changes made since the media was created is performed. Because of this, you still need network connectivity throughout the DCPROMO process, although the amount of replication required is significantly less. Because some dcpromo operations have been known to take days and even weeks, this concept can dramatically help deploy remote domain controllers.

NOTE

If the copy of the Global Catalog that has been backed up is older than the tombstone date for objects in the Active Directory (which by default is 30 days from the time the object was last validated ), this type of dcpromo will fail. This built-in safety mechanism prevents the introduction of lingering objects and also assures that the information is relatively up to date and no significant incremental replication is required.


Understanding Universal Group Caching for AD Sites

Windows Server 2003 Active Directory enables the creation of AD Sites that cache universal group membership. Any time a user uses a universal group, the membership of that group is cached on the local domain controller and is used when the next request comes for that group's membership. This also lessens the replication traffic that would occur if a Global Catalog was placed in remote sites.

One of the main sources of replication traffic is group membership queries. In Windows 2000 Active Directory, every time clients logged in, their universal group membership was queried, requiring a Global Catalog to be contacted. This significantly increased login and query time for clients who did not have local Global Catalog servers. Consequently, many organizations had stipulated that every site, no matter the size, have a local Global Catalog server to ensure quick authentication and directory lookups. The downside of this was that replication across the directory was increased, because every site would receive a copy of every item in the entire AD, even though only a small portion of those items would be referenced by an average site.

Universal Group Caching solved this problem because only those groups that are commonly referenced by a site are stored locally, and requests for group replication are limited to the items in the cache. This helps limit replication and keep domain logins speedy.

Universal Group Caching capability is established on a per site basis, through the following technique:

  1. Open Active Directory Sites and Services.

  2. Navigate to Sites, sitename .

  3. Right-click NTDS Site Settings and choose Properties.

  4. Check the Box labeled Enable Universal Group Membership Caching, as illustrated in Figure 8.6.

    Figure 8.6. Universal group caching.

    graphics/08fig06.gif

  5. Click OK to save the changes.

NOTE

Universal group (UG) caching is useful for minimizing remote-site replication traffic and optimizing user logins. Universal group caching does not replace the need for local Global Catalog servers in sites with Exchange 2000/2003 servers, however, because it does not replace the use of the GC Port (3268), which is required by Exchange. UG caching can still be used in remote sites without Exchange servers that use the site consolidation strategies of Exchange Server 2003 previously mentioned.


 < Day Day Up > 


Microsoft Exchange Server 2003 Unleashed
Microsoft Exchange Server 2003 Unleashed (2nd Edition)
ISBN: 0672328070
EAN: 2147483647
Year: 2003
Pages: 393
Authors: Rand Morimoto

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