In a previous article, “How to move objects among domains in Active Directory,” I showed you how to move computer accounts around within your Active Directory (AD) tree. Now, let’s take things a step further and examine the process of moving other types of objects, such as users and groups. Although it may not sound like a complicated process, it is. When you move users and groups within the same domain, all you have to do is just drag and drop the user. You have to jump through a few more hoops when you move objects from domain to domain. The primary tool for performing such moves is the MoveTree command, which I will explain more about in this Daily Drill Down.

The MoveTree command
The primary tool for moving objects between domains is the MoveTree command. This command is a utility built into Windows 2000 that’s capable of moving both leaf objects and root objects. There are two main stipulations to using the MoveTree command for you to remember.

First, when you move objects with MoveTree, the move must occur between domains that exist in the same AD forest, because unfortunately, you can’t move objects between forests.

Author’s note

All AD objects contain attributes defined by an AD schema that’s stored and maintained on a global catalog server, which exists at the forest level. Because two different forests would have different global catalog servers, they would most likely also have different AD schemas. Therefore, moving objects between forests isn’t supported.

You must remember to move an object to an existing location. The MoveTree utility is incapable of creating new containers. Therefore, when you move an object, you must specify a preexisting destination container into which to move the Active Directory objects. If you don’t specify an existing container, the move will fail.

MoveTree is designed to primarily move users and groups, although in some cases, it can be used to move computer accounts. However, I don’t recommend doing so. Computer accounts are better moved with the NETDOM utility.

MoveTree’s command syntax
The actual command you’ll enter will vary depending on your individual environment; you’ll have to plug in variables such as your source and destination domains. You’ll also have to enter the fully qualified domain name of both the source and the destination containers. Here, I’ve listed the command’s syntax as it appears when you enter the MoveTree /? command.

Moving users
Moving user accounts within a domain is just a matter of performing a simple drag-and-drop operation. Moving users between domains must be done with the MoveTree command; however, if you play by the rules, it’s a fairly painless operation.

Certain rules apply to any move performed with MoveTree. These rules stipulate that both the source and the destination domain exist within the same forest and the container into which you’re moving the object must already exist. However, any time you move an object with MoveTree, there are also rules specific to that object type. User objects are no exception.

When you set out to move a user object, you must first verify that the user is a leaf object. Cross-domain moves in which the user object acts as a container to some other type of object aren’t supported.

Next, verify that the user accounts you’re moving are qualified to exist in the destination domain. To do so, make sure the user names don’t already exist in the destination container. If a duplicate account name already exists, you’ll have to either rename the user objects prior to the move or move the user objects into a different container. Otherwise, the move will fail.

You must also make sure the user object’s security attributes match the destination domain’s requirements. For example, if the destination domain requires an eight-character password, but the accounts only have six-character passwords, because of loose security requirements within the source domain, the move will fail.

Before you actually begin the move process, you must also look at the user account’s group memberships to see which global groups the user account might belong to. Global groups are domain-specific. Therefore, if you attempt to move a user object and the user happens to belong to a global group, not only will the move fail but also the group membership will be voided in the process.

The exception to this rule is the user object can be a member of the domain users group, even though the domain users group is a global group, because Windows knows the account must belong to this group to be able to use the domain. At the time of the move, the user account is removed from the source domain’s domain users group and placed into the destination domain’s domain users group.

Moving groups
As with user accounts, moving a group within a domain is a simple drag-and-drop operation. However, as with user objects, you must also use the MoveTree command to move a group between two domains. When moving a group with the MoveTree command, all of the standard rules apply, along with some rules specifically for moving groups.

You must remember that a group’s memberships must remain valid after the move or else the move will fail. Needless to say, because various types of groups serve different purposes, some types of groups will be easier to move than others.

Another condition of moving a group is that the destination container can’t already contain an object with the same name as that of the group you’re moving. If a duplicate name exists, the move will fail.

Moving groups within Windows 2000
The most basic type of group in Windows 2000 is the local group. A local group exists on a local machine and can only include members whose accounts reside on the local machine, not on the domain controller. Because of the nature of local groups, you can’t move them with MoveTree.

You’ll also encounter domain local groups, which can contain members from many different domains. The group’s limitation is that it can only be assigned to resources that exist within the same domain as the group itself. Therefore, it is possible to move domain local groups with the MoveTree command, because after the move, the group’s memberships will still be valid. However, you’ll have to make sure that the group hasn’t been assigned to any resources, because the group’s resources must exist in the same domain as the group. So any resources assigned to the group prior to the move would no longer be valid after the move.

Another type of group you’ll encounter is called a global group. Global groups can be assigned to resources that exist anywhere in the forest. However, the members of a global group must have user accounts that exist within the same domain as the group itself. This means that if you attempt to move a global group, the membership will no longer be valid after the move, so the move will fail. To put it bluntly, you can’t move global groups to another domain using MoveTree.

Yet another type of group in Win2K is the universal group. Universal groups only exist in native mode. They can contain both members and resources from any domain. You shouldn’t have any trouble moving universal groups with MoveTree.

Another concept that you might encounter is called group nesting, which refers to the practice of placing one group inside another group. When you move a group, the group must be a leaf object, not a container object. Therefore, you can’t move a nested group with MoveTree.

As your company grows, the original AD structure may cease to fit the organization’s administrative and architectural needs. When this happens, you can simply reorganize the AD structure rather than having to completely rebuild your network from square one. But before you start trying to move things around, make sure you understand which groups can and can’t be moved as well as what happens to their permissions after you move them.