Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
In part 1 (
Reorganizing Active Directory
), I explained how to move objects within a domain. I then explained that a command called MOVETREE can be used to move some types of objects between domains. In this article, I’ll continue the discussion by talking about MOVETREE in more detail.
As I mentioned in part 1, MOVETREE is a tricky command. It is powerful, but many of its operations are very limited. Before I discuss the procedures involved in using MOVETREE, I’ll discuss what MOVETREE is and isn’t capable of.
Supported MOVETREE Functions
Because MOVETREE‘s entire purpose is moving objects between domains, it should come as no surprise that moving an object or a non-empty container to a different domain within the same forest is one of the supported functions. However, as open-ended as this function sounds, it has some significant restrictions: One such restriction involves working with groups. For example, you can only move domain local groups and global groups between domains (within the same forest) if the groups have no members. If the groups have members, you’re limited to moving them within their present domain.
These group restrictions don’t apply to universal groups, however. As you may recall from my series of articles on Windows 2000 groups, universal groups are specific to Windows 2000 networks running entirely in native mode. Because of the versatility of universal groups, moving them is a snap. You can use MOVETREE to move universal groups within a domain or between domains that exist in the same forest.
Unsupported MOVETREE Functions
Some types of objects just can’t be moved or have serious limitations placed on them. In this section, I’ll discuss these objects and limitations.
One such limitation involves computer objects. As you may know, in Windows 2000 it’s necessary for Windows 2000 Professional machines to join a domain by using an administrator’s password, prior to the first time a user uses the workstation as a part of the domain. The MOVETREE command is capable of moving a computer object from one Active Directory location to another. Unfortunately, doing so doesn’t disjoin the computer from its previous domain and join it to its new domain. After the move, the computer will still belong to its original domain. To join a new domain, I recommend using the NETDOM utility.
Another limitation is that although MOVETREE can move user accounts, it can’t move data associated with the user. This includes things like login scripts, user profiles, certificates, smart card information, and the user’s personal data. When moving a user, you can write custom scripts to move all the data except smart card data and certificates. These will have to be issued by the certificate authority in the new domain.
Along with the limitations I’ve mentioned, there are also certain types of objects you can’t move at all. These include system objects, which are those objects whose object class identifies them as System Only. Likewise, you can’t move objects that exist in schema naming or in configuration containers within the Active Directory. Furthermore, you can’t use MOVETREE to move domain controllers, objects whose parent object is a domain controller, and objects located in special Active Directory containers, such as the Builtin, ForeignSecurityPrincipals, LostAndFound, or System container.
| The LostAndFound Container |
In case you’re unfamiliar with the LostAndFound container, its purpose is storing Active Directory objects that have been orphaned. You can view the LostAndFound container by using the Active Directory Users and Computers snap-in for Microsoft Management Console. The LostAndFound container is found in the Advanced view. Whenever the MOVETREE command moves an object into the LostAndFound container, it assigns the object the GUID of the parent object. |
With so many limitations, you may wonder what happens if you accidentally try to move one of these objects. For example, suppose you try to move a big chunk of the Active Directory, and some of the objects I mentioned just happen to fall within that section. In such a situation, the objects that can be moved successfully will be moved. The remaining objects will be moved to the LostAndFound container in the original domain.
Troubleshooting MOVETREE
Suppose you attempt a move operation that falls within the restrictions I’ve discussed, but the operation fails. Several documented factors could potentially cause such a failure. It may seem odd to discuss troubleshooting techniques before I’ve talked about the actual move procedures, but in this particular case, it makes sense. Most of the factors I’ll discuss in this section are things you can check before you attempt a move–I’d rather that you know about these factors up front and have a successful move than to have a move fail and wonder why.
For starters, a MOVETREE operation will fail if an object already exists in the destination container that has the same name as the object you’re trying to move. Failure occurs because each object in any given container must have a unique identification. If you try to delete the preexisting object in the destination domain, the move may still fail. Often, this is due to replication latency–although some of the servers involved know that the Active Directory object has been deleted, news of the deletion may not be replicated to all of the servers immediately. The amount of time you’ll have to wait depends on your network’s replication schedule.
A MOVETREE failure may also occur due to a schema mismatch between the source and destination. Likewise, a failure can occur if the person who’s attempting the move has insufficient permissions in either the source or the destination.
If you’ve set up a move correctly and you have all the necessary permissions, but the move still fails, the situation may be caused by an unrelated failure on one of the servers involved. For example, a hard disk may become filled to capacity. Another possible cause is that the move couldn’t be completed because the Active Directory objects involved in the move were being used. This situation is comparable to trying to make changes to a file that someone else has open.
Problems Moving Users
I mentioned earlier that you can move users between domains by using the MOVETREE command. However, as you might have guessed, there are certain restrictions to moving users. Unfortunately, some of these restrictions can be significant. For starters, you can only move users as long as the user object contains no objects beneath it. If the user object isn’t a leaf object, the moving process will fail.
Another major restriction is that the user account must meet the criteria placed on user accounts in the destination domain before you attempt to move the account. This means that the user’s password must be of the length required by the destination domain. For example, if the user has an eight-character password as required by the source domain, but the destination domain requires a 10-digit password, the moving operation will fail. To get around this problem, I recommend changing passwords on user accounts prior to moving them. Even if the password length is correct, there’s a good chance that you’ll be forced to change the password after the move anyway, if the destination domain requires more frequent password changes than the source domain.
Before moving a user account, you need to check for a couple more things. First, check the destination domain for the existence of another user account that has the same name as the one you’re moving–remember, a move will fail if the destination has an object with the same name as the one you’re moving. This problem is especially common for user accounts. Many administrators use naming conventions for user accounts such as first initial, last name, or first name plus underscore plus last name; user names that follow such conventions are easy to accidentally duplicate in large organizations.
Finally, you must check the user’s group membership before moving a user account. Global groups are limited to having members from the domain the group exists in. If you try to move a user account without removing it from any global groups it’s part of, not only will the move fail, but the group membership will also be voided. There is one exception to this rule: If a user’s primary group is the Domain Users global group, and the user isn’t a member of any other global groups, the move will be successful. Windows 2000 will simply make the user a member of the Domain Users group in the new domain.
| CrossLinks |
|
Conclusion
As you can see, moving objects with MOVETREE is a little tricky, to say the least. In part 3, I’ll explain a few more restrictions that pertain to moving certain types of groups with MOVETREE. I’ll then discuss some of the actual procedures that you can use to move objects between domains with MOVETREE. //
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.
