If you’re new to the world of Windows NT, you may not be familiar with the concept of a domain structure. However, planning a proper domain structure is critical to building an efficient network. In this article, I’ll explain why domain planning is so important, and I’ll walk you through the process of planning a domain structure that’s right for you.
What’s a domain?
In Windows NT, a domain is a collection of servers that share a common set of security parameters. Perhaps you think of a user’s login account as existing on a specific server and controlling access for that server. In Windows NT, this situation is only partially the case. The user’s account exists on one server. (Copies can exist on other servers.) Rather than controlling access to that server only, however, the account controls access to every resource within the domain.
Why is planning so important?
Planning is important for several reasons. For starters, building a network can be very expensive. Improper planning can cause you to spend much more on servers, software, and client licenses than is necessary.
Second, performance is an important factor. Although Windows NT can handle a large workload, improper planning can cause your servers to suffer some terrible bottlenecks. Users will experience very slow performance, thus decreasing their job efficiency.
Finally, proper planning is critical from a security standpoint. Without accurate planning, some users may not be able to access the resources that they need, while other users or someone from outside the company may be able to gain full control over your network.
Number of users
When you’re planning your network, the first thing that you need to establish is the number of users who will be accessing the network and their respective locations. Such information is essential to good domain planning. In most cases, you’ll want to build the domain structure around geographically concentrated groups of users. For example, if you have offices in New York and Las Vegas, you might consider creating a New York domain and a Las Vegas domain.
Despite the simplicity of a geographical approach to domain design, there may be times when this method isn’t the best solution. There are many other factors to consider besides geographic location. One of the most important factors is capacity. For example, the practical limit for the number of users within a domain is 40,000. Obviously, if you have anywhere near that many users, you’ll probably want to break the domain into several smaller domains in order to improve efficiency and ease of administration.
Physical network capacity is another consideration. It would take a very powerful network to handle 40,000 users. Needless to say, these users would consume a lot of bandwidth. In situations when bandwidth is a consideration, you might consider creating the domain structure around users who have similar job functions. For example, you might have a marketing domain, a finance domain, and a systems domain. Such a domain structure, combined with an appropriate physical network design (subnetting), would keep much of the network traffic isolated within the individual domains, rather than flooding the entire network.
Another issue to consider is the domain’s administrative burden. In large organizations, it may be impractical for the systems department to manage every aspect of the domain. In some cases, it may be more effective for each department to manage its own resources. There are two ways of doing so.
The first way is to create a separate domain for each department. Each domain could contain that department’s user accounts and shared resources, such as files and printers. Such an arrangement would force each domain to have its own administrator, who would be responsible for creating and deleting user accounts and for assigning permissions to resources.
If you’re not willing to relinquish that much control, there’s another method. You could divide the network into user domains and resource domains. Each resource domain would be dedicated to a department. Basically, a resource domain would consist of one or more servers that would host shared resources, such as files and printers. The user domain, on the other hand, would contain all of the users in the company. A security officer would manage the user domain and would be responsible for creating and deleting user accounts.
All of the resource domains would trust the user domain. When someone needs access to a resource, the administrator of the resource domain simply gives that user access to the resource. For example, suppose that the marketing department gets a new employee. When the systems department verifies that person’s employment status, it creates an account for the user. Once this account has been created, the marketing director can grant the user access to the marketing shared files and printers. Using this method takes much of the administrative burden off of the systems department, without forcing that department to give up complete control.
Once you have a basic idea of the type of domain structure that’s suitable for your organization, it’s a good idea to consider costs. The first thing that you’ll need is a client license for every computer that’s logged in simultaneously. If you use per seat licensing instead of per server, however, you’ll usually spend less because you won’t have to buy an extra license for every server to which your clients connect.
You’ll also have to remember that Windows NT Server costs more than Windows NT Workstation does. Each domain must have an NT Server working as a domain controller. Microsoft strongly recommends that all domains have another server that functions as a backup domain controller. A backup domain controller contains a copy of all of the security information, and it can take over automatically if the primary domain controller gets busy or drops off-line. You also must remember that large domains may require more than one backup domain controller. If a Windows NT Server is dedicated to being a domain controller but serves no other function, you can get away with having one backup domain controller for about every 1500 workstations. (Keep in mind that this number could go down if the backup domain controller isn’t very powerful or if it’s sharing file and print resources or running other services.)
In this article, I explained that it’s very important to plan your domain properly. A poorly planned domain may contain security holes or lead to massive bottlenecks, and it could be very expensive to build.
This article also explained the various aspects that you should consider when you’re planning a domain structure. These aspects include licensing issues, security, and the geographic layout of your network. Finally, I described some methods of making multiple domains work together.
Brien M. Posey is an MCSE who works as a freelance technical writer and as a network engineer for the Department of Defense. If you’d like to contact Brien, send him an e-mail. (Because of the large volume of e-mail he receives, it's impossible for him to respond to every message. However, he does read them all.)The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.