Create Additional GC Servers
If you have more than one AD domain in your forest, you'll likely need to configure some of your DCs as GC servers. The GC contains a subset of the data from all the domains in the forest, whereas an ordinary DC has information about its own domain only—which is why you shouldn't need additional GC servers in a single-domain environment, wherein each DC has complete information about every object in the forest.
At logon, the GC server provides information about a user's universal group memberships. DCs also query the GC to resolve user principal names (UPNs) for other domains. For example, suppose a user with a UPN of beth.jones@acme.com logs on to a computer that's a member of the northeast.acme.com child domain. The DC in northeast.acme.com consults the GC to find out which domain contains Beth's account.
By default, only one GC server exists—the first DC in the root domain—but you can create more if you need them. Ideally, you should have at least one GC server in each Win2K site to keep GC queries off your WAN links. (If you implement Microsoft Exchange 2000 Server, you should try to have a GC server on every subnet that contains an Exchange server because Exchange makes even heavier use of the GC.)
You can use the Active Directory Sites and Services snap-in to make any DC a GC server. Expand the Sites container, then expand the site that needs a GC server. Expand Servers, then expand the server to which you want to assign this role. You'll see an NTDS settings object beneath the server. Right-click that object, select Properties, then select the Global Catalog check box, as Figure 3 shows. However, be aware that this change creates additional replication traffic across any links to this server. You might want to revisit your site configuration and replication schedule to make sure they'll accommodate the increased network traffic.
Set the Operations Masters
AD uses a multiple-master model, which means that you can make changes to the directory on any DC. (With NT 4.0, by contrast, you must make changes on the PDC.) Some changes, however, such as creating a new child domain, must be managed by one server to prevent conflicts. For this reason, the first DC in each domain takes on three specific roles, called Flexible Single-Master Operation (FSMO) roles: PDC emulator, relative ID master, and infrastructure master. The first DC in the forest root domain gets two additional FSMO roles: schema master and domain naming master. To learn about the functionality of each FSMO role, see the sidebar "Masters of Your Domain."
When you have more than one DC available in a domain, you can shuffle these roles around for load balancing and fault tolerance. (AD FSMO roles aren't automatically reassigned if an operations master fails.) You must use different tools to change these roles. You can use Active Directory Users and Computers to transfer the three domain-specific roles—PDC emulator, relative ID master, and infrastructure master—to other DCs. Simply right-click the domain, then select "Operations Masters." In the Operations Master dialog box, select the RID tab, which Figure 4 shows, then transfer the appropriate role to another DC.
Each forest has only one domain naming master. You can use Active Directory Domains and Trusts to transfer this role. Right-click Active Directory Domains and Trusts, then select Operations Master.
Each forest has only one schema master. To transfer this role, you must first make the MMC Active Directory Schema snap-in available by registering its supporting DLL. To do so, click Start, Run, then type
regsrvr32 schmmgmt.dll
Next, add the Active Directory Schema snap-in to an MMC console. Then, within this console, right-click the Active Directory Schema and select Operations Master to transfer the schema master role to another DC.
If one of the operations masters fails, you can use ntdsutil.exe to seize its role. However, doing so can cause inconsistencies if you manage to bring the original master back online. With the possible exception of the PDC emulator, users generally won't notice the absence of the operations masters, and administrators need to use them only occasionally. If you can do without the failed master while you're repairing it—for example, if you can avoid creating new domains until you get a failed domain naming master back online—you should leave the FSMO role alone.
Prev. page
1
2
[3]
4
next page 
