by Marcin Policht
Placement, Installation, and Verifying Functionality of a Global Catalog
A typical Windows 2000 domain controller replicates schema (AD Schema information) and configuration (most notably, Site and Services information) naming contexts with all other domain controllers in a forest, however the replication of domain naming context takes place only among domain controllers within a same domain. If there were a request for information about an object from a different domain, a controller would have to "walk the tree" searching for the target domain in order to refer to one of its controllers. This would considerably affect the speed of forest-wide queries.
Using a Global Catalog allows for circumventing this obstacle, when querying for objects outside of requester's domain. Global Catalog contains index of all objects in the forest and a small, most commonly used, subset (about 60 out of 1500) of their attributes . This eliminates most of the time the need for requester's searches through other domains in a forest (unless one of non-typical attributes is searched for). The number of attributes stored on each Global Catalog server can be modifed by using Schema Management snap-in (by selecting "Replicate this attribute to the Global Catalog" option for selected attributes of an object)..
In addition, GCs are used by default in a native mode environment when looking up universal group information during login. If any one of the GCs can not be contacted, users are not allowed to logon to the domain (if cost of placing a high performance server in a site is prohibitive, this requirement can be eliminated by modifying HKLM\SYSTEM\CurrentControlSet\Control\Lsa\IgnoreGCFailures registry entry - in such case, though, the use of universal groups is discouraged). Therefore, at least one Global Catalog per site should be available.
Global Catalog is installed automatically on the first domain controller in the forest. Subsequent installations (or relocation of original GC) are up to forest and domain administrators.
Global Catalog should not be placed on the same server as infrastructure master. The role of infrastructure master is to update references from objects in its own domain to objects in other domains. This is done by comparing its data with that of a global catalog. If the infrastructure master finds out that its data is outdated, it requests the update from the global catalog and then sends the updates to other domain controllers in the domain.- if they happen to be the same server, the infrastructure master would never be able to find that the data is out of date and update other domain controllers in the domain. However, it is recommended to place the infrastructure master in the same site as a Global Catalog server.
A Global Catalog should reside on the same server as a Domain Naming Master (which typically is also a Schema Master).
In order to verify a proper functioning of Global Catalog you can try one of the following:
- check the DNS server (you can use NSLookup or simply launch mmc Snap-in). Search for type SRV records - when using NSLookup, use set type=SRV option, and then type the fully qualified name pointing to the GC down in DNS hierarchy - e.g. _ldap._tcp.gc._msdcs.swynk.com or _ldap._tcp.sanfransite._sites.gc._msdcs.swynk.com
- after assigning a GC role to a server, check its Directory Services event log for event number 1119, which indicates successful obtaining a role of a Global Catalog server
- use Replication Administrator RK tool to verify the consistency of the information on the GC using the format repadmin.exe /kcc sfserver001.swynk.com or repadmin.exe /showreps sfserver.swynk.com
- use LDAP browser or ADSI Editor to connect to the port 3268 (Global Catalog communication is performed over TCP port 3268, regular LDAP lookups are sent to TCP port 389).