Capabilities of the MOVETREE Command - Page 2
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.
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.