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 repadmin utility in Windows Server 2012. The repadmin
utility indicates which portions of the AD database are replicated to
different domain controllers in a forest and how recently they have
been updated.
Repadmin enables an administrator to determine the replication status of each domain naming context in the forest. The command is repadmin /showrepl <server name>.
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 repadmin. For example, the fully replicated global catalog server in Figure 6
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 6. Repadmin GC creation verification.
Global Catalog and Outlook in Exchange Server 2013
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 2013, the Outlook client access to the directory has
been changed. Outlook clients communicate with the RPC Client Access
Service on a Client Access server. 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.
Understanding Universal Group Caching for AD Sites
Windows
Server 2012 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 that 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.
The universal group caching capability is established on a per-site basis, through the following technique:
1. On the domain controller, open the Active Directory Sites and Services tool.
2. Navigate to Sites, sitename.
3. Right-click NTDS Site Settings, and choose Properties.
4. Check the Enable Universal Group Membership Caching check box, as shown in Figure 7.
Figure 7. Universal group caching.
5. Click OK to save the changes.
Note
Universal group (UG) caching is useful for
minimizing remote-site replication traffic and optimizing user logons.
Universal group caching does not replace the need for local global
catalog servers in sites with Exchange 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
previously mentioned.
Exploring Microsoft Exchange Active Directory Topology Service
The
relationship that Exchange Server 2013 has with Active Directory is
complex and often misunderstood. Because the directory is no longer
local, a special service was written for Exchange to access and process
information in AD. Understanding how this service works is critical for
understanding how Exchange interacts with AD.
Understanding Microsoft Exchange Active Directory Topology Service
Microsoft
Exchange Active Directory Topology service is one of the most critical
services for Exchange Server 2013. The Microsoft Exchange Active
Directory Topology service is used to discover current Active Directory
topology and direct Exchange to various AD components. The service
dynamically produces a list of published AD domain controllers and
global catalog servers and directs Exchange resources to the
appropriate AD resources.
In addition to
simple referrals from Exchange to AD, Microsoft Exchange Active
Directory Topology service intelligently detects global catalog and
domain controller failures, and directs Exchange to failover systems
dynamically, reducing the potential for downtime caused by a failed
global catalog server. Microsoft Exchange Active Directory Topology
service also caches LDAP queries made from Exchange to AD, speeding up
query response time in the process.
On
start of the Exchange Server 2013 services, the Microsoft Exchange
Active Directory Topology service queries Active Directory and
determines which domain controllers and global catalogs are available.
It also chooses one as the configuration domain controller. A 2081
event in the application event log is generated. Microsoft Exchange
Active Directory Topology service then polls the Active Directory every
15 minutes to identify changes to site structure, domain controller
placement, or other structural changes to Active Directory. A 2080
event in the application event log is generated each time. By making
effective use of LDAP searches and global catalog port queries, domain
controller and global catalog server suitability is determined. Through
this mechanism, a single point of contact for the Active Directory is
chosen and maintained, which is known as the configuration domain
controller.
