Microsoft

Organizing and maintaining Active Directory

Active Directory can present a challenge to a new Windows administrator, especially when migrating from Windows NT. Here's what you need to know about AD to properly design your Active Directory tree.


Active Directory forms the heart of Windows Server 2003. One of the keys to making Windows Server 2003 really function well is to do a good job designing and maintaining Active Directory. The problem for a new Windows administrator, or one who is moving from Windows NT to Windows Server 2003, is how to go about designing an effective Active Directory structure.

Active Directory design
The philosophy behind a good Active Directory design doesn't differ very much between Windows 2000 and Windows Server 2003. The best advice that I can give anyone on organizing an Active Directory is to take into account both your current needs and any growth that may occur in the foreseeable future. Windows Server 2003 is very flexible in the ways that it allows you to reorganize an Active Directory. However, the reorganization process tends to be much easier if you have a good Active Directory design to start with.

Initial design considerations
When you initially begin designing your Active Directory structure, there are several things that you need to consider. First, is there an existing network? Second, if there is an existing network, is it Windows Server-based, and, if so what version is being used?

Other important considerations include how many different locations your company has and how many users are at each location. Finally, you also need to think about who will be responsible for administering and maintaining each portion of the network. Will the IT staff administer the entire thing centrally or will some departments manage their own resources?

Preexisting networks
For the purposes of this article, I will assume that you don't have a network in place yet and that you will be designing Active Directory structure from scratch. If you do currently have a network in place, though, you can still use most of my techniques. The biggest thing that you must remember is that as you make the transition to an Active Directory environment, within each Windows NT domain, the PDC must be the first domain controller to be upgraded to Windows Server 2003. I also recommend carefully reading the section on functionality levels later on.

Active Directory Integrated DNS
The first step in planning your Active Directory environment is to plan your organization's DNS implementation. As you probably know, a DNS server translates domain names and URLs into IP addresses. Without a DNS server, domain names and URLs can't be resolved and, therefore, your computers will have no idea how to contact other computers on your network or on the Internet.

If you currently have Internet access, you may be confused as to how Internet access can work when you don't have a DNS server. Normally, your ISP should have a DNS server, and this server's address is entered into your computer's TCP/IP configuration.

However, your ISP's DNS server is insufficient for running an Active Directory. Not only is a DNS server an absolute requirement for Active Directory, the DNS server that you use must be able to support Active Directory Integrated Zones. This means that the DNS server must be running on either Windows 2000 Server or on Windows 2003 Server.

Because Windows requires a DNS server that supports Active Directory Integrated Zones, the first domain controller that you bring online must also double as a DNS server. For larger networks, you will eventually want to bring one or more dedicated DNS servers online and then point all of your servers and workstations at the dedicated DNS servers. However, if you have a smaller network, then there's no reason in the world that you can't continue to run the DNS services on your first domain controller.

The only way to really tell whether or not your domain controller will work as a long term DNS server solution is to go ahead and install any other server applications that may be required on the server and do some performance monitoring. By using performance monitoring, you will be able to tell whether or not the server has adequate resources for all of the workload being placed on it.

Site planning
Once you have figured out which server will act as your first domain controller and as a DNS server, the next step in the planning process is to plan your organization's site structure. Implementing sites are a way of cutting down on replication-related network traffic over slow WAN links. Generally, the site structure should mimic your network's geographic boundaries. Each WAN link should usually have a corresponding site link.

This doesn't necessarily mean that you have to go crazy creating a million sites, though. Windows 2000 Server had a tendency to bog down after you created about 200 sites. Windows Server 2003 has fixed this problem, but Microsoft has actually started reducing the number of sites on their own network by combining a lot of smaller sites to form a bigger site. Even so, I still think that creating a site structure that mimics your WAN structure is a good idea.

The reason for this is that normally, when you make an administrative change such as creating a user account, the change is written to a domain controller. Through the process of replication, the domain controller must synchronize that update with every other domain controller in the organization.

Imagine that you had a remote office with ten domain controllers. If someone in the main office made a small administrative change, the change would have to be written to each of the ten domain controllers in the remote location. This means passing the exact same information over the WAN link ten different times. Obviously, this doesn't make for an efficient use of bandwidth.

Now, suppose that you implemented a site between the two offices. When you do, Windows designates one domain controller in each location as a bridgehead server. When someone makes a change in the main office, the change is replicated only to the servers in the main office.

The domain controller acting as the bridgehead for the main office collects the changes and then sends them to the bridgehead server in the remote office at a scheduled time. The remote office bridgehead then receives the changes and distributes them to the domain controllers in the remote office.

This example is a little oversimplified, but, as you can see, the information related to Active Directory update is only passed over the WAN link once as opposed to ten times. Generally speaking, implementing sites works really well. The biggest thing to remember is that you must have at least one domain controller in each site.

Furthermore, if there are Windows 2000 domain controllers within a site, then I recommend designating your bridgehead server to act as a global catalog server. Otherwise, if the WAN link goes down, users within the disconnected site may not be able to log in. If your domain controllers within the site are all Windows Server 2003-based, then you won't experience this problem.

Domain structure planning
In Windows, a domain is simply a collection of user and computer accounts that are often located in close geographic proximity and administered by a common user or group. Domains are also completely independent of the site structure. Normally, a site will span a WAN link, and it's also common for each facility to use its own independent domain. This often gives the illusion that the domain and the site structures are somehow related. The reality, though, is that there is no reason why a domain can't span a site link.

It would be easy to write an entire article on domain planning, but since I have a limited amount of space to work with, I will give you the basics of domain design.

Normally, when you create a domain, the domain should reflect some type of structure within your organization. It is common to base domains on users, resources, or geographic proximity.

When a domain is based on geographic proximity, the domain will contain both users and resources (such as computers, printers, file servers, etc.). A geographic domain structure may relate to the company's physical location. For example, you might have separate domains for offices in Miami, Las Vegas, and New Orleans. However, geographic domains can exist on a much smaller scale. For example, within an individual office you might have domains for various departments, such as accounting, marketing, and sales.

In addition to geographic or departmental domains, you may also have domains that are based on users or resources. I have seen several companies in which all of the user accounts exist within one domain while all of the file servers and printers exist within a separate domain. The idea behind this type of organizational structure is that one administrative team can handle shared resources while another only worries about managing user accounts.

To be perfectly honest, however, domain planning isn't nearly as important in Windows Server 2003 and in Windows 2000 Server as it was in Windows NT. Although domain planning is still important, much of the management that previously occurred at the level is now performed at the OU level.

When I set up a network that is entirely Active Directory-based (no Windows NT domain controllers), I tend to use a geographic domain model. The only reason for this is because doing so greatly reduces the amount of replication-related network traffic outside of an individual office or department. In the end, though, every office is going to be different, and you really just have to figure out what kind of domain plan makes sense for each individual company.

OU planning
The next Active Directory structure that I want to discuss is the Organizational Unit or OU. An OU is yet another organizational structure within Active Directory. An OU is independent of the organization's site structure, and exists at the domain level. An OU provides a mechanism for better managing Users And Computers within a domain.

To see how an OU works, imagine that there is a company with a thousand users and all thousand users and their workstations exist within a single domain. In the old days, it would have been a major hassle for the administrative staff to manage such an organization. Password resets alone would probably be a fulltime job. Of course, the administrative staff would probably also have to deal with a lot of office politics. There is always at least one department that seems to want to take control away from the IT staff and manage the network themselves.

A few years back, this situation would have presented some major problems. After all, imagine if the "problem department" took their case to the president of the company and you were forced to turn over the administrative password to the idiot who was running the department.

This is where OUs come into play. Suppose that the department that was trying to take over the network was the finance department. In such a situation, you could create an OU called Finance. You could then move all of the user accounts and computer accounts that were related to the finance department into this OU.

Now, rather than handing over the administrative password, you could simply delegate someone from finance as having full permissions to administer that OU. By doing so, you have kept the finance department and the president of the company happy but have preserved the integrity of the network. If the people in the finance department were to mess something up, their mistakes would be limited to the OU that they have been delegated control over and could not damage the rest of the network.

Although OUs are often created for the purpose of delegating authority, they can be used as a mechanism for implementing a group policy as well. For example, suppose that you had a group of computers that were publicly accessible. You would probably want to apply a tighter security policy to these computers than to the rest of the computers in the domain. In this situation, you would want to create an OU and move those computers into it.

The reason is that Windows takes a hierarchical approach to security. Group policies can be applied at the computer, site, domain, and OU levels. The various group policies are combined to form the effective policy. Policy settings in a higher-level group policy override settings in a lower-level policy. Since the OU is the highest level, any settings that you apply to an OU will override security settings applied elsewhere. As you can see, creating multiple OUs and corresponding security policies allows you to implement tougher security where it is needed most without overly restricting other areas of your network.

Delegation
Now that you know what an OU is and have a general understanding of how it works, I want to talk a bit about delegation. In my last example, I discussed the possibility of creating a dedicated OU for the finance department and delegating someone from finance control over the OU. However, delegation isn't an all or nothing operation. There are various levels of delegation. In fact, delegation doesn't necessarily even have to be applied to an OU.

When I was setting up my last example, I said that just handling password resets for my fictitious organization would probably be a fulltime job. In Windows NT, anyone who was responsible for resetting passwords required administrative permissions. However, Windows 2000 and Windows 2003 allow you to delegate the right to reset passwords to someone. That person will then be able to reset passwords without having any other administrative authority granted to him. The person's account has the same rights that it always did, with the exception of being able to reset passwords.

Delegating authority is done through Active Directory Users And Computers console. You can delegate authority either at the domain level or at the OU-level. Simply right-click the desired location, and then select the All Tasks | Delegate Control commands from the resulting shortcut menu. This will launch a wizard that you can use to specify who you are delegating control to and what level of control you wish to delegate.

Functional levels
Functional levels are another one of those topics that it would be easy to write an entire article on, but I want to give you the Readers Digest version. Basically, each version of Windows Server has its own capabilities. In an Active Directory environment, the entire Active Directory's capabilities are limited by the oldest operating system on a domain controller. For example, if you have a Windows 2000 network, you won't be able to use universal groups and several other features until all domain controllers are upgraded to Windows 2000 and each domain has been switched to native mode.

In Windows 2000, native mode refers to a domain running entirely Windows 2000 domain controllers and mixed mode refers to a domain that also contains Windows NT domain controllers.

In Windows 2003, the concept is extended a bit. The concept of mixed mode and native mode still exists, but now it is called the functional level. In Windows 2003, you can set the functional level to support NT, 2000, and 2003, or just 2000 and 2003, or 2003 only. You can only use the Windows 2003 only mode once all domains have been upgraded to Windows Server 2003. The primary advantage of switching to the Windows Server 2003 functionality level is that, after doing so, you will be able to rename domains.

Editor's Picks