Reorganizing Active Directory to better meet your needs

You can organize Active Directory pretty much any way you want. But just as soon as you get it the way you want it, you?ll probably have to reorganize it. Talainia Posey shows you how to reorganize your Active Directory tree.

One of the big ideas behind Active Directory (AD) is that its structure should mimic the structure of your company. However, if you just upgraded from Windows NT and used the default AD configuration, AD probably isn’t organized optimally. Even if you’ve created a good AD structure, a corporate reorganization could quickly dictate the need to change everything. Fortunately, when you need a major AD restructuring, you don’t have to completely throw out your old directory and start from scratch. Instead, you can simply rearrange what you have. In this article, I’ll discuss some ways to reorganize objects within your AD.

Organizing AD
There are actually many different ways that you can organize AD to meet the needs of your company’s structure. One popular method is to divide AD into organizational units (OUs) based on department. For example, you might have an OU for the finance department and another for the marketing department. Of course, all of these OUs are still a part of the same AD, and users within one OU can still see objects elsewhere in AD (assuming you have given them permission to do so).

The advantage of grouping each department into a separate OU is that group policies can be applied to individual OUs. This means that you can easily apply a single set of security policies to an entire department. If a new employee is hired, simply make him or her a member of the appropriate OU, and all of the department’s security policies will automatically be applied. Likewise, if a user changes departments, simply move the corresponding user object to the new department’s OU and the user will lose the permissions to the old department and gain the permissions of the new department.

Before you start moving objects around though, you need to know that the method that you’ll use to move the objects will depend largely on the object’s location. You’ll use different methods depending on whether an object’s current location and future location exist within the same domain or in different domains.

Moving objects within a domain
The process of moving objects that share a common domain is extremely simple, but there are a few things to keep in mind.

First, it’s possible to move multiple objects simultaneously. This means that if you’re restructuring AD for the first time and have a large number of objects to move, you can move large numbers of objects with just a few mouse clicks.

You also need to know how the move affects an object’s security, which depends on how the permissions were applied in the first place. As I mentioned, any time that you move an object to a different OU, the old OU’s permissions cease to apply and the permissions that are associated with the new OU take effect. An object would keep its original permissions only when the permissions were assigned at a level other than the OU level. For example, if a group policy had been applied to the domain level, then simply moving an object to a different OU within the same domain wouldn’t get rid of a domain-level group policy permission scheme. Likewise, permissions that were assigned directly to an object would still apply to that object regardless of where it exists within the domain (unless another permission overrides it).

Now that you know a little bit about the consequences of moving AD objects around within a domain, let’s take a look at how to do the actual moving. To move an object, open Active Directory Users And Computers utility. When the console opens, select the object you want to move. (You can select multiple objects by holding down the [Ctrl] key and clicking on each object that you want to select.) Now, right click on the object or objects that you’ve selected and select the Move command from the resulting context menu. When you do, you’ll see the Move dialog box shown in Figure A. Then, select the location to which you want to move the objects and click OK.

Figure A
Select the container to which you want to move the objects and click OK.

Moving objects to a different domain
As you can see, moving objects within a domain is easy, but moving objects to a different domain can be tricky. Unfortunately, you can’t move objects between domains with a simple drag-and-drop operation like the one you use to move objects within a domain. Instead, you’ll have to resort to using a command-line utility called MOVETREE.

Although the MOVETREE utility is included with Windows 2000, it isn’t installed by default. Instead, MOVETREE is a part of the Windows 2000 Support Tools. So you’ll have to install the Support Tools to gain access to the utility. To do so, insert your Windows 2000 Server CD. When you see the splash screen, select the option to browse the CD’s contents. Then, navigate through the CD’s directory structure to the \SUPPORT\TOOLS directory and run the Setup.exe program.

Once you’ve installed the Windows 2000 Support Tools, you can move objects between domains. Before doing so, though, let’s take a look at what actually happens when you move an object or a group of objects.

As with Windows NT, every object in Windows 2000 is assigned a security identifier (SID) number. The SID number acts as a security identifier. The SID uniquely identifies the object to Windows so that Windows can know which security attributes to apply to the object.

When you move an object to a new domain, the object keeps its globally unique identifier number (GUID) but takes on a different SID. The new SID is used to associate security attributes that are applied after the move with the object. However, in most cases, the object will need to retain some of its previous security attributes that were associated with the previous domain. To do so, the object makes use of a Windows 2000 attribute called SID History. This attribute compiles a list of every SID number that’s ever been associated with the object. Therefore, Windows 2000 still uses the GUID to identify the object, but when creating the object’s access token, it looks at all of the object’s SIDs and applies the security information that’s associated with them. The drawback to this technique is that it only works in Native Mode.

Now that you have an idea of how the move process works, let’s take a look at some other issues that you’ll encounter. One of the things that you might be wondering is which types of objects can be moved. The MOVETREE utility allows you to move users, groups, organizational units, servers (including domain controllers), and workstations between domains. In general, there are some heavy restrictions on interdomain moves and some even bigger restrictions on some of the types of moves that I’ve mentioned. In fact, in some cases, I recommend using an alternate tool for the move. Perhaps the biggest restriction with all moves between domains is that the move must take place between two domains within a common forest. Remember that if two domains are in different forests, then they have no knowledge of each other and don’t share a common AD schema or global catalog. Therefore, the move is impossible.

Another restriction is that whatever type of object you’re moving, you must move it into a container that already exists within the new domain. The MOVETREE utility can’t create a new container for you.

Why did the move fail?
Although it may seem odd at first, I want to go over a few troubleshooting techniques before I begin demonstrating the actual move process. As I mentioned, the process of moving AD objects between domains involves using a command-line utility. As with many other command-line utilities, the syntax can be rather complex, and there is a strict set of rules that you must to adhere to. This leaves a lot of room for things to go wrong.

By knowing the factors that can cause a failure, you can avoid making a mistake at the time of the move. One possible cause of a failed move is that the object that you’re moving is locked. As you probably know, AD is designed in such a way as to allow multiple users to access it simultaneously. Because of this, the entire directory is never locked. However, it is possible that Windows can lock a portion of AD. For example, any time that you create a child object, the child’s parent object is locked during the creation process. Any time that an object is locked, it can’t be moved until the lock has been released.

Another cause for failure is a schema mismatch. The two domains that you’re moving objects between must be within the same forest. Because they do exist within the same forest, the domains share a common global catalog and AD schema. A schema mismatch would occur in situations where the two domains don’t actually belong to the same forest. You could also have a schema mismatch if you made a big change to AD and the change hasn’t finished replicating to all of the domain controllers. In such a situation, some domain controllers within the forest would have the new schema, while other domain controllers would still have the old schema. A replication related schema mismatch will take care of itself when the next replication cycle completes.

Another replication related failure would be a situation in which you tried to move an object that had been deleted. Remember that when you delete an AD object, the object is only removed from a single domain controller. The deleted object remains on all other domain controllers until after the next replication cycle has completed. Therefore, if you attempt to move such an object, the object may appear to be valid because it still exists on the domain controller that you’re looking at. However, a move would fail because the deletion process has already been initiated.

A more common cause for a failed replication might be running out of hard disk space on the destination domain controller. Invalid login credentials for either the source or the destination domain would also cause the move process to fail.

AD’s structure should mimic your company’s organizational structure. However, many times this means that you’ll have to reorganize AD to better meet your needs. Reorganization can be a daunting prospect, but it doesn’t have to be as challenging as you think if you do a little bit of preplanning and know what all is involved.

Editor's Picks