A checklist to help you avoid checkmate
Setting up Active Directory (AD) is a lot like chess: You must plan ahead but also strategize as you go, making sure that you don't lose your king because you've become obsessed with your pawns. You might find yourself preoccupied with setting up the domains, organizational units (OUs), groups, and user accounts, but you shouldn't forget a fundamental IT principle: When you make a change, make sure it works. After you promote a Windows 2000 member server to a domain controller (DC), you should run through a checklist to ensure that the promotion went smoothly and make some simple but important configuration changes to ensure that the DC is working when you need it to. Let's review the checklist you should step through as you configure an AD domain.
Check All Event Logs
Each time you run Dcpromo, check for error messages on all the event logs on every DC you promote. I recommend that you perform this step early, before you continue with the process and complicate the environment with other installations and configurations. As with construction, you should address any problems you find with the foundation before you build the rest of the structure on top of it.
Check DNS for SRV Records
AD doesn't work without DNS—period. You must install the DNS service and enable dynamic updates before you even think about installing AD. AD makes heavy use of SRV records, which are a relatively new type of DNS record that identifies servers running specific services on your network. Microsoft uses SRV records to identify the location of AD-related services, such as Lightweight Directory Access Protocol (LDAP) servers.
When you install your first AD DC, the Netlogon service creates several SRV records and the special domain nodes that contain them—but only if your DNS server is capable of dynamic DNS (DDNS). Win2K DNS supports DDNS, but Windows NT 4.0 DNS doesn't. (However, be aware that with Win2K DNS, the DDNS option is disabled by default.) Without DDNS, you must create all the AD nodes and records manually—which is neither fun nor easy.
To make sure that Netlogon has created the SRV records and nodes, open the DNS administration console after the server has booted as a DC for the first time. Under the AD domain name, you should see four new child nodes: _msdcs, _sites, _tcp, and _udp, as Figure 1, page 70, shows. (If the server is a Global Catalog—GC—server, you should also see a _gc node.) Look for SRV records within these nodes. If you select the _tcp node, for example, you should see at least three SRV records for each server: two for Kerberos (_kerberos and _kpasswd) and one for LDAP (_ldap).
If you see the four (or five) nodes and SRV records within them, you're ready to move on. If you don't, wait a few minutes (the Netlogon service might require some time to register the nodes), then refresh the DNS display. If you still don't see the SRV records, verify that DDNS is enabled. To do so, select the DNS forward lookup zone for your AD domain. Right-click the zone, then select Properties. Select the General tab and make sure that Allow dynamic updates is set to Yes, as Figure 2 shows. If it isn't, change the value, then restart the Netlogon service on the DC to force registration of the SRV records.
Check for the Ntds and Sysvol Folders
The AD installation process creates two subfolders—Ntds and Sysvol—within the root of the system folder (usually C:\winnt). When the promotion process finishes, open Windows Explorer and make sure these folders exist.
The Ntds subfolder contains the AD database, ntds.dit, and its supporting files, such as the transaction logs. The Sysvol subfolder is the shared system volume and contains items shared among all DCs, such as the script files that Group Policy uses. The new File Replication Service (FRS)—the next generation of the NT 4.0 Directory Replication service—will automatically replicate the contents of this folder to other DCs in the same domain.
Check the Computer Account
As with NT 4.0, all Win2K machines, including DCs, need computer accounts to function in a domain. If you open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in and select the Domain Controllers OU, you should see a computer account object for the DC you just installed. The AD installation process creates this computer account for the first DC in the domain. If you promoted a member server in an existing domain, Dcpromo will have moved its computer account to this OU.
If the computer account doesn't exist, something went awry during the AD installation. The same is true if the Ntds and Sysvol subfolders don't show up. These problems are quite rare, but if they arise, you must uninstall AD from this DC, then reinstall it.
Secure the Administrator Account
Whenever you create a new domain, you should rename the domain administrator account and give it an appropriately complex password. This basic security step is often overlooked.
As you know, all Win2K and NT 4.0 domains contain a powerful account named "administrator:" by default. Don't make things easier for potential intruders. Rename the account. And don't name it after your favorite superhero; use a generic-sounding name (e.g., Sue Johnson) to hide the account among your user accounts.
Select a password that will send the best cracking software into conniptions. AD account passwords can contain up to 127 characters, so you can now use a passphrase to protect the administrator account. As always, use a mix of upper- and lowercase as well as alphanumeric and nonalphanumeric characters. The longer and more complex the password, the better.
I also recommend that you create a second domain administrator account in case you forget the first one's long, secure password. Follow the same principles set out above for its name and password. And remember that this step is only the first and most basic step in securing your servers.
Set the Site Membership
You must set the DC's site membership to ensure that both replication and logon traffic don't overburden your WAN links. Although Win2K member servers and Win2K Professional systems will automatically join the correct site according to their IP address, a DC's site membership is static and usually requires that an administrator set it. If, however, you've already created the sites and their corresponding subnets, and if you can set the DC's IP address to the one it's supposed to have before you run dcpromo.exe, the DC should join its intended site automatically.
But if you plan to set up or change site configurations after installing the DCs, you'll have to adjust their site memberships manually using the MMC Active Directory Sites and Services snap-in. This is also the case if you have to configure the DC with a different IP address from the one it will have permanently—for example, if you're setting up the server and shipping it to a branch office. And at the very least, you'll have to modify the site membership of the first DC in the forest root because you have to install AD on it before you can create any sites. A cautionary note: Before you change its site membership, make sure the DC's IP address matches the address of one of the subnets assigned to its intended site.
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
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.
Configure the Time Service
You must configure your DCs so that they synchronize their clocks with one another. The AD installation wizard makes no mention of this requirement, but it's a vital post-installation task. The good news is that you have to perform this step only once per AD forest; the bad news is that if you don't do it, you'll probably find within a week that none of your users can log on.
Time matters because of Kerberos, the protocol that AD uses for authentication. Kerberos won't issue credentials if the time on the Key Distribution Center (KDC—all AD DCs are KDCs) and on the client requesting authentication differs by more than 5 minutes. Furthermore, if two DCs' clocks are out of sync, replication between them will fail. Because most computers' internal clocks are woefully inaccurate, this discrepancy isn't hard to achieve. (If your company has offices located in several states or countries, don't worry; Kerberos takes time zone differences into account.)
To prevent this problem, you must configure the PDC emulator in the forest root domain to synchronize its clock with an external time source. If you're not sure which machine is the PDC emulator, follow the steps in the previous section as if you're going to transfer the role, but merely look it up instead.
To set the external time source, open a command prompt on the PDC emulator, then type
Your ISP should be able to provide you with either the name or IP address of a Network Time Protocol (NTP) or Simple Network Time Protocol (SNTP) server. In a pinch, you can use one of the US Navy's time servers at tick.usno.navy.mil or tock.usno.navy.mil, but it's better to use a server that's geographically close to your server and to avoid overloading the navy's servers.
After you establish the external time source, the other DCs will automatically synchronize their clocks with the PDC emulator's clock, and time will synchronize in a cascading fashion throughout the forest. The member servers and Win2K Pro machines will synchronize their clocks with a DC in their domain. Also, PDC emulators in child domains will synchronize their clocks with the PDC emulator in their parent domain. Then, the DCs in that domain will synchronize with their domain's PDC emulator. The member servers and workstations sync with the DCs, and so on down through the hierarchy of domains, until all clocks on all Win2K machines are in sync.
Checking Out
AD is big, new, and complex. You'll have your hands full just getting the user accounts working. The last thing you need is a mysterious problem with a new DC that could slow or even halt your AD rollout. By completing a simple checklist to make sure your DCs are properly installed and configured from the first day, you can substantially reduce the amount of AD troubleshooting you'll have to do—both initially and for the lifespan of the directory's implementation in your company.
