The Accounts Database

Capacity planning with NT

The first time most companies install Windows NT, the installation is often for a small test group. But as NT expands to the rest of the organization, even on a small scale, some planning is necessary. Previous articles (see "Related Articles in Windows NT Magazine") have discussed the concepts of domains and how to use groups to organize your users. The subject of this article is how many users to put in a domain. I'll look at how many users you can put in a domain and what that number implies for the size of your accounts database. I'll then examine how the database file size, plus other variables such as password policies, can affect network traffic. With this knowledge, you can deduce how many users you should put in the domain.

When Size Matters
Why is the size of the accounts database so important? Well, disk space is only one issue. A large accounts database requires a large server to handle the database. Users do not expect to wait for logon validation, nor do they want to wait for authorization to access a resource. So you must be able to load the accounts database into memory and keep it there. If your domains contain large numbers of users, your domain controllers will require more memory than the recommended minimums for running NT.

First, let's get one issue out of the way. People often ask, "What is the maximum number of users I can put in a domain?" The upper limit on accounts in a domain is a moving target. The largest number anyone has tried so far is about 40,000. This number is a practical limit, not a software limit.

Notice that I talk about accounts, not users. An account can be a user, a group, or a computer. Yes, an NT computer that is a member of the domain has an account. You add these accounts in Server Manager when you let a computer join the domain. Or, you add them when you install NT on a new computer and you use your administrator account and password to enroll that computer in the domain. Windows 95, Windows 3.1, and Windows for Workgroups computers do not have accounts, so they do not add to the size of the database.

Each type of account takes up a fixed amount of space in the accounts database, so the mix of accounts, not just the number of accounts, is important. A computer account takes 512 bytes. A user account occupies 1024 bytes. A local group takes 512 bytes for the group, plus 36 bytes for each member of the group. And a global group takes 512 bytes for the group, plus 12 bytes for each member of the group.

The difference in size between local and global groups is easy to explain. A global group can contain users from only its domain, so all a global group needs to store is the username. A local group can contain global groups from the same or other domains, and users from its own or a trusted domain. So each entry in a local group has to be large enough to accommodate the domain name and the user or group name.

Does It Measure Up?
If you have a domain with 1000 users, each with an NT computer, you can quickly calculate the size of the accounts database. A user account occupies 1000 * 1024 bytes, or about 1MB. A computer account takes up 1000 * 512 bytes, or about 0.5MB. But you also have to allow for the group information, which is a little more complex because it involves some estimates. You have to make some educated guesses about how many groups the average user belongs to.

Suppose each user is a member of four global groups (on average). Remember that each user is by default a member of the Domain Users group, so you can assume each has membership in three other groups. Not everyone will be in the same three groups, so suppose you have 20 global groups. Twenty global groups occupy 20 * 512 bytes, or 10KB. Four thousand memberships at 12 bytes each equals 48KB. The global group membership needs just under 60KB, which is not very large compared to 1.5MB for the user and computer accounts.

You can apply a similar calculation to local group membership. In this case, you are only concerned with the local groups on the domain controllers because they are the sole contributors to the domain accounts database. If you add each user to the local Users group on the domain controller, that one group takes 36,512 bytes. However, the NT domain model handles user accounts more efficiently so that the local groups do not contain large numbers of users.

Look on your domain controller. You'll find that the user accounts are members of the global group Domain Users, not members of the local group Users. The global group Domain Users is a member of the local group Users.

Previous articles gave reasons for putting users in global groups and then placing the global group into the appropriate local groups. Consider one more reason. Let's say you want 800 of 1000 users to have access to a SQL Server database. You build a local group SQLUsers, which contains all 800 names. This group's contribution to the accounts database is 29,312 bytes. But if you put all the users into a global group, GL_SQLUsers, that group takes only 10,112 bytes. Placing one entry--the GL_SQLUsers--into the local SQLUsers group requires 512 plus 36 bytes, so you have now used 10,660 bytes instead of 29,312 bytes.

OK, so saving 18,652 bytes is not such a big deal given today's cheap hard disks. But multiply that number by 50 or 100 groups, and the disk space adds up.

Mixing It Up
Let's look at numbers for different user and computer mixes to see how the database size increases as you add to the domain. Some examples have fewer computers than users because multiple users can log on at the same machine or, more realistically, because the users have domain accounts but are running Win95 on their desktop computers. Win95 computers do not register in the accounts database.

Table 1 shows accounts database sizes. Now before you start sending email about the typo in the last line of the table, think about what it shows. You are not looking at only 100 users with NT computers and the remaining users with Win95. You have a master domain, or accounts domain, where the users have their accounts. Those users who have NT computers have registered them in the resource domains, so they do not show up in this accounts database.

If you want to push the existing boundaries and build the world's largest NT domain, plan to have 40MB of memory in your domain controllers just for the accounts database, in addition to what NT Server needs for itself and other tasks. Besides lots of memory, you'll want a fast computer and a good disk subsystem: Think how long it will take just to load the accounts into memory when you boot the server. If you have only a couple hundred users, a 486DX4-100 can work as a domain controller, but you need at least 32MB of memory on such a system. At 10,000 users, you'll want a Pentium 133 with 48MB or 64MB of memory. And for 40,000 users, plan on a Pentium Pro, possibly with multiple CPUs, or a DEC Alpha, with 128MB of memory.

And One More Thing
Let me offer another compelling reason to watch the size of your accounts database. Any changes you make to the user or group accounts take place at the Primary Domain Controller (PDC). The PDC must replicate the changes to the Backup Domain Controllers (BDCs). This replication can result in significant network traffic. You may add or delete users, modify group assignments, and make a few other changes each month. But the biggest volume of changes can be from your users. No, they do not have permission to directly modify the accounts database, but what are your password policy settings? Do the user account passwords expire at frequent intervals? If you have 20,000 users who must change their password every 60 days, you'll have 10,000 changes per month replicated to each BDC--10,000 user accounts at 1024 bytes each, or 10MB of data. Spread over 20 working days, this number might not be much for a LAN. But it is a significant load on a WAN link, especially a 28.8Kbps modem. You can do the math: The load is approximately 8 hours of data transfer, just for passwords.

A little planning goes a long way with user accounts, groups, and domains. Perhaps you are setting up your first NT server. To avoid problems down the road, be aware of how your accounts database can grow and the implications of that growth. Until you see NT 5.0's new directory service, two of the hardest tasks in NT are splitting one domain into two and combining two domains into one. (For information about the new directory service, see Mark Smith, "Dfs: One Piece of the New Directory Service Solution," December 1996, page 119.) You don't have a simple path to move user accounts and groups. Avoid the pitfalls of making your domains too large or overly fragmented: Estimate their size, and then decide how to best manage both users and resources.

RELATED ARTICLES IN WINDOWS NT MAGAZINE:
Ed Tittel and Mary Madden
- "Domains, Trust Relationships, and Groups," June 1996
- "PDCs, BDCs, and Availability," August 199