People are poking and prodding Active Directory (AD) as it moves from backroom labs into the real world. Consequently, some gotchas in the first generation of Windows 2000's directory service are coming to light. A few are trivial, but others aren't. Here's a quick look at four of those gotchas.
Avoid Membership Change Collisions
One of AD's strengths is its replication model. Instead of Windows NT's single read/write PDC backed up by some read-only BDCs, every AD domain controller is read/write. A complex multimaster replication structure ensures that every domain controller knows about the changes that every other domain controller receives. Replications compress data as much as 10 to 1 before transmission over slow WAN links, and administrators can schedule when those replications take place.
When you change a user-account attribute under NT 4.0, NT replicates the user's entire record; AD replicates only the changed attribute. However, AD stores a group's membership as one attribute. The list of a group's users and machines (yes, groups can contain machine accounts in AD) resides in that attribute. The catch is that attributes have a maximum size in the AD database, and AD doesn't have room for more than 5000 SIDs in a group's membership attribute. (This gotcha doesn't limit the built-in Domain Users group, however, which apparently doesn't suffer from the 5000-member cap.)
In combination with multimaster replication, group membership as an attribute creates another potential problem: membership change collisions. The demise of the single-master model makes a new scenario possible. Suppose a company's domain controllers in St. Louis and Ottawa are in the same domain. A group called FaxServerOperators contains the names of the users who can administer some fax server software. Now suppose that Laura, a domain administrator in Ottawa, adds herself to the FaxServerOperators group and that Steve, an administrator in St. Louis, adds himself to that group at about the same time.
Both additions change the Members attribute of the record that describes the FaxServerOperators object. Laura's and Steve's changes are replicated locally and across the WAN at about the same time, and eventually the changes collide. AD uses an algorithm to determine who wins, but basically the winner is the user whose change was made last.
Maybe you don't often modify group memberships, so the possibility of changes colliding doesn't worry you. But if you want to ensure that changes to group memberships don't collide, you might want to return to the days of NT 4.0, so to speak. You can choose one of your domain's controllers as a kind of administrative clearinghouse and tell all administrators that before they modify a group's membership, they need to focus the Active Directory Users and Computers administrative tool on that clearinghouse domain controller. (To change domain controllers, double-click the Active Directory Users and Computers administrative tool, right-click the icon for your domain, choose Connect to Domain Controller, then type the name of the domain controller that you want to work with.)
Make Changes on Domain Controllers Near the Client
Here's some advice for administrators in geographically scattered domains: Don't assume that AD's replication structure will respond quickly enough to serve your clients' needs. Let's return to the St. Louis and Ottawa example, but let's make Steve a typical user with no administrative powers and Laura an administrator at the company's centralized Help desk. Steve needs to change his AD account, perhaps because he's in a different department or his phone extension has changed. He contacts Laura, who updates his AD record. How long will it be before Steve sees the change?
Both St. Louis and Ottawa have domain controllers. When Steve queries AD about his account, he probably queries a domain controller in St. Louis. However, when Laura makes the AD change, she likely communicates with a domain controller in Ottawa. If she and Steve worked at the same site, that site's domain controllers would all become aware of the change within a fairly short time—domain controllers replicate changes to other domain controllers at the same site within 15 minutes. But the speed of replication across WAN links depends on the design of your AD replication structure. Frequent updates across WAN links spread news of account changes quickly but also suck up WAN bandwidth. If Laura and Steve's company is parsimonious in its use of WAN bandwidth for replication, Steve's local domain controllers might not see the change for a while. Laura can minimize the delay by focusing Active Directory Users and Computers on a domain controller near Steve when she makes the change. By initiating the AD change in St. Louis rather than Ottawa, Laura ensures that Steve's local domain controllers quickly see the account change. The cost is that Laura must change the account through a domain controller that communicates with her at WAN speeds rather than LAN speeds.
What if Steve asks Laura to give him a new password, and she does so while she's connected to the Ottawa domain controller. Will Steve have to wait for Ottawa to replicate the password to St. Louis? No; Win2K treats passwords a bit differently. If Steve tries to log on in St. Louis before his local domain controller knows of his new password, his logon will fail. But before reporting the failure, the St. Louis domain controller communicates with the domain controller that acts as the PDC Flexible Single Master Operation (PDC FSMO).
So what is the PDC FSMO? Although AD is a distributed, decentralized database system, a few AD functions must be centralized. One such function is the old NT notion of a PDC. In a mixed-mode AD domain, NT 4.0 BDCs need a PDC to replicate from. The Win2K domain controller that acts as the PDC FSMO serves that function.
In a native-mode AD domain, such as the one in our St. Louis and Ottawa example, the PDC FSMO doesn't serve the PDC function but still has a job: ensuring that password changes take effect immediately across the domain. Most AD replication can take a long time to complete within a domain, and that delay can cause problems: Steve might not be able to wait for the domain controllers to finish replicating his password change. So, AD appoints one of its domain controllers as the PDC FSMO. Whenever an AD domain controller gets a new password, the domain controller immediately replicates the password to the PDC FSMO. When Steve's logon attempt fails, the local domain controller immediately retries the logon on the PDC FSMO, even if the PDC FSMO is across a WAN link. That machine always has the most up-to-date password and authenticates Steve for
St. Louis.
Use GC Servers in Single-Domain Forests
One benefit of AD forests is that although they might contain many domains, administrators can easily give a user in one domain access to machines in all the other domains in the forest. So a user from one domain should be able to easily log on to a machine that belongs to another domain. But how does that machine know which domain the user belongs to? Without that information, the machine can't find a domain controller to authenticate the user.
The answer is often the Global Catalog (GC), a database made up of a subset of information from every domain in the forest. Suppose a user logs on as [email protected] and her user account is in a Win2K domain named southeast.sales.holdingcompany.com. She logs on at a Win2K machine as mary@acme .com, and that machine asks a GC server, "Where can I find the domain that can authenticate [email protected]?" The GC server responds, "In southeast.sales.holdingcompany.com."
Part of AD planning involves figuring out how many GC servers you need to help make logons happen quickly and where to put those GC servers. You might like to be able to make every domain controller into a GC server. But keeping all of those GC servers up-to-date would slow down the network and the domain controllers. AD planners need to seek a balance between network response time and the number of GC servers.
The GC is an essential part of logons for any multidomain forest. But in a single-domain forest, only one domain can log on a user, so a GC seems irrelevant, doesn't it? Well, yes and no, according to Andreas Luther, one of three Microsoft folks who give presentations about AD and how it works. (These presentations are quite good and worth attending if you get the chance.) According to Luther, although single-domain forests shouldn't need GC servers, some server applications (he didn't say which) seek out a GC server regardless of the number of domains in a forest. So, you might want to have as many GC servers around as possible, to keep that sort of application happy.
Making a domain controller a GC server is costly in terms of server performance in a multidomain forest, but not in a single-domain world; the process of distilling a single domain into a GC is simple and fast. So, if you have a single-domain forest, you might consider making all your domain controllers GC servers.
Choose Names Carefully
Some things never change. After you create a domain, you can't change its name. To work around this restriction, you can create a new domain with a new name, then use a directory migration tool to copy user and machine accounts to the new domain. However, that process isn't simple.
You can't rename a domain controller, either—at least not without a bit of work. As long as a PC is a domain controller, you can't rename the domain controller. But Win2K lets you shift a computer's role from domain controller to member server and back without reinstalling the OS. You can run Dcpromo (the AD Installation Wizard), convert the domain controller to a member server, rename it, then convert it back to a domain controller. That's a lot of work to rename a domain controller, though, so you need to pick your domain names carefully.
