Enabling GCs
Under AD Sites and Services, expand Sites. Select a site, expand it, and select a DC. Right-click NTDS Settings, and the General properties page will display a GC check box, which lets you enable (select) or disable (clear) the GC. Simply selecting the check box doesn't mean that the GC is now available and ready for use. Don't forget that replication still needs to take place. The Directory Services event log will contain event ID 1119 when replication is complete and the GC is available to service queries.
Determining GCs
You can use a variety of GUI, command-line, and scripting methods to determine which of your DCs are currently configured as GCs. In addition to the Sites and Services snap-in, you can also use Repadmin, a command-line tool in the Support Tools folder on the Win2K CD-ROM. To launch Repadmin, use the command
C:\>repadmin /showreps
domain_controller
where domain_controller is the DC you want to query to determine whether it's a GC. The output will include the text DSA Options: IS_GC if the DC is a GC.
If you want a listing of all GCs in the forest, the simplest method is to use the Dsquery tool found in the %systemroot%\system32 folder. To launch Dsquery, use the command
C:\>dsquery server forest isgc
You can run Dsquery on only Windows 2003 or Windows XP platforms. If you don't have access to Dsquery, you can use the Active Directory Replication Monitor (replmon.exe). After you launch the application, choose any of the DCs under Monitored Servers in the left pane. (You might need to add a DC first.) Right-click the DC and select Show Global Catalog Servers in Enterprise, as Figure 2 shows. In the Show Global Catalog Servers dialog box, which Figure 3 shows, select the DC and click OK. A new window, which displays the GCs, will give you the option to log the results to a text file. Identify the port that the GC listens on for LDAP queries. The GC uses port 3268/TCP for incoming LDAP queries and port 3269/TCP for LDAP Secure Sockets Layer (SSL) connections.
Placing the Infrastructure Master on a GC Server
Make sure that the DC that's holding the Infrastructure Master FSMO role isn't configured as a GC. To determine which DCs hold FSMO roles for a particular domain, I like to use Netdom, a command-line tool that you'll find in the Support Tools folder on the Win2K CD-ROM. To launch Netdom, use the command
C:\>netdom query FSMO
Designating the Infrastructure Master as a GC isn't a good idea. The Infrastructure Master maintains references from objects in its own domain to objects in other domains. Group membership is an example of this scenario. A group in Domain A can contain members from Domain B. If one of the group members in Domain B is renamed, the updated information (i.e., the distinguished nameDN) somehow needs to be passed to the DCs in Domain A so that they can display the accurate group membership information. The Infrastructure Master holds records, known as phantoms, in its directory database that represent these objects from other domains. Periodically, the Infrastructure Master queries a nearby GC to determine whether any changes have been made to the objects for which it holds phantom records. If the Infrastructure Master detects changes, it will remove the old phantom and create a new record that contains the updated information. The Infrastructure Master then replicates the updates to the other DCs in the domain. Don't enable the Infrastructure Master as a GC because the GCs already have information about objects in other domains and therefore won't create the required phantom records. In other words, the Infrastructure Master won't be able to fulfill its role.
When you install your first AD DC, the system automatically configures it as a GC server. The system also assigns the first DC in the forest all five FSMO roles. This action appears to go against the rule for GCs and the Infrastructure Master role, but the rule has two important exceptions. If you have only one domain, the Infrastructure Master has no need to update object references to other domains because no other domains exist. The second exception occurs if all the DCs in a single domain in a multidomain forest are also GC servers, which means they're all up-to-date and don't need updates from the Infrastructure Master. In these scenarios, which DC holds the Infrastructure Master role isn't important.
Sergio Fonseca March 14, 2004