Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2010 : Defining the Global Catalog (part 2)

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 replicates 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 2 contains the default naming contexts, such as Schema, Configuration, and DnsZones, in addition to domain-naming contexts for all domains. In this example, the companyabc.com domain has been replicated successfully to the DC2 domain controller.

Figure 2. Replmon GC creation verification.

Global Catalog and Outlook in Exchange Server 2010

In Exchange Server 2003 and Exchange Server 2007, Outlook clients would make direct calls to global catalog servers. This made them susceptible to failure or demotion of domain controllers with global catalogs. In many cases, the failure of a global catalog server would require the restart of all Outlook clients that were using it for lookups.

In Exchange Server 2010, the Outlook client access to the directory has been changed. Outlook clients communicate with the RPC Client Access Service on a CAS. This service proxies the global catalog lookups for the Outlook clients rather than having them query the global catalog directly. This reduces the direct dependency of Outlook clients on the global catalog, allowing for better scalability and faster recovery if a global catalog failure occurs.

Deploying Domain Controllers Using the Install from Media Option

When deploying a remote site infrastructure to support Exchange Server 2010, take care to examine best-practice deployment techniques for domain controllers 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 and Windows Server 2008 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 advanced options including to install from media, as illustrated in Figure 3.

Figure 3. Install from media option.

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 in very large organizations have been known to take days and even weeks, this concept can dramatically help deploy remote domain controllers.

Understanding Universal Group Caching for AD Sites

Windows Server 2008 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 Server Active Directory, every time clients logged on, their universal group membership was queried, requiring a global catalog to be contacted. This significantly increased logon 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 logons speedy.

Universal group caching capability is established on a per-site basis, through the following technique: