Designing an Active Directory naming scheme

By Brien M. Posey | Aug 24, 2000 | Print this Page
http://www.enterprisenetworkingplanet.com/netsysm/article.php/623871/Designing-an-Active-Directory-naming-scheme.htm

If you'd like to learn more about fully qualified domain names in large organizations, an excellent poster comes with the Windows 2000 Server Resource Kit. This poster illustrates the concepts that I've discussed in this article in an easy-to-follow format.

Several years ago, I worked for a company that started its network with a single server and four users. By the time I was hired, the network had grown to 4 servers and 70 users. When I left the company, the network had grown to almost 30 servers and 1,200 users.

This growth taught me a valuable lesson about network design. Because no one had ever planned for the network to grow, the initial design scheme of the network didn't allow for much growth. All user accounts were simply the first name of the user, and the servers had names such as Server1 and Server2. This lack of foresight caused some serious growing pains later.

Regardless of the size of your network, you should design it as though it will someday become a huge network. In this article, I'll discuss some ways of doing this by designing an appropriate Active Directory naming scheme.

Spotting the forest and the trees

In a pure Windows NT environment, there is relatively little to know as far as structure goes. You have domains and trust relationships between them, and that's about it. As a result, you can't get very creative with your network design. Sure, you can break things into user domains and resource domains, but the same basic limitations still apply. This isn't the case in Windows 2000, though. Windows 2000 contains many more subdividing elements that you can use to develop the network structure. Before you can really design an effective network plan in Windows 2000, it's necessary to know something about these elements.

One of the first concepts that you need to understand is the difference between trees and forests. Trees and forests describe the basic structure of your network. In most cases, tree structures are appropriate for small to medium-size businesses, while forests are more appropriate for large or very diverse organizations.

Unless you're very new to Windows, you're no stranger to trees. Windows Explorer is a good example of a tree. It starts with a root: My Computer. From there, it branches out into drives, and then into directories and subdirectories within each individual drive. In the context of Windows 2000, a tree refers to a similar structure. The main difference is that instead of the root being My Computer, the root is your DNS root. For example, Brien_Posey.COM could be considered the root level of my network. Branches below the root would all be based on the root name Brien_Posey.COM. Branches might have names such as CORP.BRIEN_POSEY.COM or ENG.BRIEN_POSEY.COM. Each branch can have other levels beneath it. For example, CORP.BRIEN_POSEY.COM could have FINANCE.CORP.BRIEN_POSEY.COM and MARKETING.CORP.BRIEN_POSEY.COM beneath it; see Figure 1.

Figure 1
Figure 1: A network tree.

As you can see, the basic tree structure is diverse and offers a lot of room for expansion. However, it may not be the best choice for large companies. All names are based on the root, which can get confusing if your organization happens to own more than one company. Suppose your company is structured in such a way that company A owns company B and C. Now, imagine that company A isn't strictly a holding company--each company is a normal company with brand recognition. In such a case, where company names are well recognized, it's probably not a good idea to use a tree structure. Consider the company 3com Corp., of Santa Clara Calif., which owns US Robotics. Because both are well-known companies and US Robotics was established before the acquisition, it wouldn't make sense to use naming conventions such as USR.3COM.COM--especially when USR.COM already exists. In such an example, it makes more sense to use a forest model for the network.

In a forest model, each root domain name maintains its individuality. In terms of our earlier example, a forest could consist of COMPANY_A.COM, COMPANY_B.COM, and COMPANY_C.COM. Each of these dot-COMs represents a unique root that can be the beginning of a tree structure. Thus the name forest, because a forest is a group of trees.

Naming conventions

Now that you understand the difference between trees and forests, you can start developing some structure and naming conventions within your organization. Remember the growth issues in the network described at the beginning of this article--many of the problems were due to bad naming conventions. The server names were meaningless, and the user name format didn't leave room for growth. The first step to avoiding these problems is to create a meaningful DNS structure. A good structure that uses meaningful names will propagate down to all levels of your network, thus making it easy to see where any individual network component fits into the picture.

You can use two basic organizational structures: organizational and structures. Either structure can be used in a tree or forest model. Both types of structure have advantages and disadvantages.

Organizational naming

The organizational structure reflects your company's organizational chart. For example, the root level might be known as ADMIN.COMPANY_A.COM. In most companies, the administrative department is over all other departments, so other levels might have names like FINANCE.ADMIN.COMPANY_A.COM or MARKETING.ADMIN.COMPANY_A.COM. This particular design works well for smaller organizations; the layout is easy to understand and it reflects the company's organizational structure. For example, suppose that you had a server called PAYABLES in a normal Windows NT domain structure. In such an environment, it may be difficult to see where such a server fits into the big picture. However, if the server has the address PAYABLES.FINANCE.ADMIN.COMPANY.COM, there is no question where the server fit in.

This particular structure naturally allows for growth. It has some disadvantages, though. Perhaps the biggest is that many companies rewrite the organizational chart frequently. Imagine having to reconstruct the network every time your company reorganizes! If that thought scares you, then this design probably isn't the best choice. Another disadvantage is that the design doesn't work well for organizations that are geographically distributed.

Geographic naming

A geographical naming convention often uses a structure that may be new to you. A site generally separates each location into a manageable unit. Although sites are new to Windows 2000, they have existed within Exchange Server for years. Therefore, if you're already well versed in Exchange, you already know about sites.

In a geographical structure, you might have site names such as Miami, Istanbul, Tel Aviv, or Helsinki. You can then establish a naming structure that incorporates your site names. For example, you could use names like MIAMI.COMPANY_A.COM. The advantage of geographical naming is that it uses names that tend to be persistent. After all, no one is going to change Miami or New York's name tomorrow. Because the names are persistent, geographical naming conventions often allow you to be more flexible when designing your network than if you were using the organizational structure. The major disadvantage is that geographic naming doesn't represent your company's true structure.

Mixed naming

Because both organizational and geographic structures have advantages and disadvantages, it sometimes makes sense to use a mixture of the two in really large organizations. Whether this makes sense for your business depends on the size and diversity of the various offices. For example, consider a small chain of banks. The branch banks all do the same thing and don't have many different departments. Because it's a small chain, the corporate office probably has an accounting division and maybe a human resources division, but that's about it. In such a simple organization, it wouldn't make sense to over-complicate things with a mixed naming convention--a geographic convention would work fine.

Now, consider a large chain of insurance companies. Each branch office may have its own finance and human resource departments. In such a case, mixed naming makes sense. After all, remember the earlier example of the server named PAYABLES. Imagine trying to determine the location and purpose of such a server within a big organization without a mixed naming convention. However, if the server had a name like PAYABLES.FINANCE.MIAMI.COMPANY_A.COM, it would be easy to ascertain the server's location and purpose. If necessary, in an extremely large company, you could break down the naming structure further to something like PAYABLES.FINANCE.5TH_FLOOR.4TH_STREET_OFFICE.MIAMI.COMPANY_A.COM. //

CrossLinks

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the Director of Information Systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.