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.